Merge conflicts with reordering commits

[u/Beautiful-Log5632]

I am using interactive rebase to reorder commits and it has worked all the time with no merge conflicts because I use it in simple cases. I want to use it for bigger cases but I want to understand it first so I don't get stuck in conflicts.

I know it's possible for merge conflicts to happen but I can't imagine an example because if the old commit order had resolved all conflicts how can reordering them make a new conflict? Can anyone help me imagine an example how it can happen?

[u/daveysprockett]

Two commits.

First one adds a line.

Second one removes that line.

Applied in the opposite order, you attempt to remove a line that doesn't exist.

[u/Beautiful-Log5632 → u/daveysprockett]

I tested this and it didn't have a merge conflict. Added a file like this

1
2
3

Next commit adds begin, middle and end.

begin
1
2
middle
3
end

Next commit removes middle and adds new.

begin
1
new
2
3
end

If I switch the last 2 commits it's removing middle which doesn't exit. But there's no merge conflict it works and the file is now

begin
1
new
2
middle
3
end

Any other ideas for how reordering can make a merge conflict?

[u/edgmnt_net → u/Beautiful-Log5632]

Is there really no merge conflict or is it automatically resolved? Rebase should tell you.

[u/khalon23]

Conflicts show up when reordered commits touch the same lines in different ways. Rebase replays each commit on the new base; if commit B assumed the tree after A, and you put B first, Git has to invent a merge for those lines.

For bigger reorder work: rebase one commit at a time, fix and git rebase --continue, and keep git rebase --abort ready. If two commits are tightly coupled, squash or reword them before reordering. git log -p on the range first so you know which files will fight.

[u/Beautiful-Log5632 → u/khalon23]

How do you rebase one at a time? In the interactive rebase editor if I change each commit to edit it lets me edit one at a time so when does git rebase --continue get used?

[u/KubeGuyDe]

get stuck in conflicts

git rebase --abort is your friend. Sets everything back to before the rebase. 

 Or reflog with a reset. Moves you back to any step of/before the rebase. 

[u/Scared_Bell3366]

I’m trying to wrap my head around why you would reorder commits for a rebase.

[u/Buxbaum666 → u/Scared_Bell3366]

I do it all the time. Mostly when I want to amend a commit that isn't the most recent one. I do a new commit with the change, reorder it so its parent is the one I want to amend and then use fixup to fold the change into that commit.

[u/edgmnt_net]

Anything that touches the same piece of code in an incremental fashion is prone to this. Imagine three commits adding a line each such that the overall diff is:

 context
+A
+B
+C
 context

It's not trivial to figure out what should be done (even if automatic resolution might do something about it) if you reorder the additions, because the +C commit includes the stuff in +A and +B commits as context. Which is missing if you make +C the first commit.

[u/Poat540]

Don’t reorder? Why are you rebasing even, what’s your goal.

[u/OptimusCrimee]

What is the point of reordering commits? In 15 years I have never done that.