Why git auto-resolved this conflict?

Question

Steps to reproduce the situation 1. Create file test.txt in your git master with content

A
B
C

and commit it.

Create new branch test-v1
In master branch remove line B, so you have just
```
A
C
```
Cherry-pick commit from step 3 to test-v1
Checkout branch test-v1 and add B line again and commit
```
A
B
C
```
Checkout master branch
git merge test-v1

What I expected to get:

    A
    B
    C

What I got:

    A
    C

Question: Why is B auto-resolved and not marked as merge conflict when merging?

I tried different merge strategies (git merge --strategy), but I did not find any where I would get the expected result. The only way was to git rebase test-v1 on master. But I suppose in more complicated setup, it could rewrite history of master, right?

Related: http://stackoverflow.com/questions/27930402/why-does-a-conflict-occur-for-only-one-commit-instead-of-two-in-my-rebase-operat/27944468 — jub0bs, Aug 05 '15 at 08:07
The question I link to also asks why a conflict did not occur. — jub0bs, Aug 05 '15 at 10:46

ckruczek · Answer 1 · 2015-08-05T08:20:11.067

As we already discussed in the git IRC and with big help of thiago, which is a registered user on Freenode and a experienced git user, I'll take his answer and put it here for completeness:

At the point you branched off 'test-v1' the file test.txt does have the content

A
B
C

in both branches, master and test-v1.

Now you are applying changes in master to test.txt and cherry-pick them to branch test-v1. After that you checked out test-v1 and added the B back to the file. What will happen now when you merge? Imagine I am git now:

Ok let me look up the common ancestor: Ahh ok I got it, file test looks like A B C
Lets look for the changes made in test-v1: Hmm ok looks equal to the common ancestor
Lets look for the changes made in master: Ahh ok, something changed, lets take the modifaction into account

-> Result

A
C

Why git auto-resolved this conflict?

1 Answers1