-1

I have been trying to carry out some rebases and merges in different conditions in test repositories I have crested just for this reason.

Here is my understanding about merge conflicts, they arise basically when the feature branch has changes that differ from the changes of the master from the commit where they separate.

Here is my branch structure of the repository I am testing out.

     C (feature)
    /
   B
  /
 A-----D (master)

Contents of each version are just a single file called file

A:

line 1
line 2
line 3
line 4

D:

changed line 1
line 2
line 3
line 4

B:

line 1
changed line 2
line 3
line 4

C:

line 1
changed line 2
changed line 3
line 4

Now when I execute git merge master feature, I am shown a merge conflict with the following contents of my file,

<<<<<<< HEAD
line 1
changed line 2
changed line 3
||||||| 00f97ec
line 1
line 2
line 3
=======
changed line 1
line 2
line 3
>>>>>>> master
line 4

Here's my understanding of how git would go about merging the files:

  • It would compare the 3 commits namely A, D and C.
  • It would check whether C or D have added or deleted any line and also if A had it or not.
  • Say C added a line which was neither in A nor added by D, then it would be in the final commit.
  • The only case in which a conflict must arise is when either branch adds or deletes a line and the other branch makes modifications to the same line AND that same line should also be present in their last common ancestor ie A.

But this is not the case for my repository, then why are the conflicts arising. Please correct me if my understanding of merge conflicts is wrong.

ParthGala
  • 13
  • 5
  • See https://softwareengineering.stackexchange.com/questions/194788/why-doesnt-git-merge-adjacent-lines-without-conflict – matt Apr 14 '20 at 11:08
  • 2
    Also [Why does git produce a merge conflict when lines next to each other are changed?](https://stackoverflow.com/questions/29276880/why-does-git-produce-a-merge-conflict-when-lines-next-to-each-other-are-changed) – matt Apr 14 '20 at 11:08
  • Particularly well described here https://stackoverflow.com/questions/55275340/why-do-changing-adjacent-lines-but-modifying-independently-cause-a-git-merge-con – matt Apr 14 '20 at 11:14
  • Look at it like a computer. Only line 4 is stable. Everything else changes in two different ways. That’s a conflict. Git doesn’t know what you want so it asks you. – matt Apr 14 '20 at 11:22
  • Thank you so much @matt, this was such a buggy thing, I was scratching my head for 2 days for a test case I'm trying to write(how ironically) for the git source code itself to solve a noobie bug. All the links here were helpful ! – ParthGala Apr 14 '20 at 12:37
  • Cool, but the idea is that _you_ search, and you search _before_ (preferable _instead of_) asking a new question that has been dealt with before. – matt Apr 14 '20 at 12:54
  • I tried to search this on google, but it generally always leads to other blogs which teach you to merge or stack overflow questions of a similar kind, but not this very specific case of two adjacent lines being edited(my bad I didn't search directly on stack overflow, which would have probably got me the above links). As I asked in the question, I was of the fact that my understanding of the way merge works may be wrong in itself. So I thought asking a question directly would be wiser than wasting any further time. But yes will search stack overflow next time onward as well. – ParthGala Apr 14 '20 at 13:58

1 Answers1

1

The rule for a content conflict to happen is very simple: git sees that two branhes modified the same section of code in different directions. Could be added/added, added/modified, added/deleted, modified/modified, modified/deleted or deleted/deleted.

In your particular case, you have a conflict because all the lines that make up the content of the conflicting section are modified. From A to D the modified line has line 2 after it. But on the other branch that line is gone and so git won't make any guesses at what you might want to get as a result of that merge and so it conflicts. If there were a fixed separation between those two lines that made it through both branches (something like ----), there would be no conflict.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • I think "section" is the key here. I also found it confusing that modified/modified on **different** lines results in a conflict, since when you do the manual merge there is nothing to do... So I think the fact that neighbouring lines are the same section is important to keep in mind. That way I don't have to feel nervous about the fact that I can't see any conflicting lines in my merge nor any out of order issues. It's a "just double-check" conflict, perhaps. – Heath Raftery Sep 13 '22 at 04:27