CODEWITHSUNDEEP
gitmergerebase
nz_21
nz_21

Reputation: 7343

Understanding rebase conflict vs merge conflict with an example

I am trying to come up with an example where a rebase conflict is different from a merge conflict.

I understand what the individual terms -- rebase and merge -- mean. But I don't quite understand how they could create different conflicts.

Could someone point me in the right direction with an example?

Upvotes: 1

Views: 118

Answers (2)

Mark Adelsberger
Mark Adelsberger

Reputation: 45659

In practice, conflict differences should usually arise from the fact that rebase applies commit patches one at a time whereas merge looks only at the final state of each branch (and the merge base - the last commit common to the branches).

So if you have

o --- x <--(master)
 \         
  A - B - C  <-(feature)

and want to combine feature with master, maybe o-A patch conflicts with o-x even though o-C patch does not - in the simplest case because B or C undoes something that A did. Then a rebase will create conflicts that a merge will not.

Also, it is possible that you resolve conflicts for A during a rebase, and that changes the course of the rebase as it applies B and C. That's a little harder to visualize since it depends on how you edit the worktree during rebaase conflict resolution, but in theory it could happen.

Additionally, there are several ways that a merge can result in different final content than a rebase. I suppose you could manipulate those scenarios into cases where conflicts differ.

Why would the content differ? Well it shouldn't, and the cases where it does are weird edge cases that, in my opinion, arise from rebase trying too hard to be clever - but regardless they almost never come up in practice.

Upvotes: 0

Tim Biegeleisen
Tim Biegeleisen

Reputation: 521093

Here is a simple and somewhat contrived example. Let's say that you branched off the main branch according to this diagram:

main:   .. A -- D
            \
feature:     B -- C

And you have a function in a certain source code file:

function foo() {
    int a = 3;
    return a;
}

Let's say that, for whatever reason, you decided to add one line in commit B:

function foo() {
    int a = 3;
    int b = 10;
    return a;
}

In the second commit C, you removed the added line, leaving the code as it was when you branched off from the main branch.

At the same time, in the main branch, someone else has now made a new commit D which also added a new line:

function foo() {
    int a = 3;
    int c = 5;
    return a;
}

If you were to rebase your feature branch on the main branch, the code would start off above with the int c = 5 line in the D commit. But then reapplying your first B commit would give a merge conflict, because the two parents each tried to add a new line to the same spot, in the same function. You would resolve that conflict, and then choose whichever version you wanted.

However, if you instead were to merge the main branch into your branch, there would be no conflicts. The reason for this is that your feature branch is starting off at the C commit, whose source code is identical to the A commit in the main branch. So, only a single change to the function would happen, coming from the main branch, and there would likely be no conflict.

The rule of thumb for merge conflicts in rebasing versus merging is that in general they may not be the same. Rebasing reintroduces your work (commits) on top of a new base, and each re-commit can cause merge conflicts. On the the other hand, merging introduces a single delta into your target branch, all at once.

Upvotes: 2

Related Questions