-1

So there is master that goes

   m1->m2

and a branch that goes

     m1->m2
       \
        ->b1->b2

I did a merge of master into branch making it

   m1->m2         mb(merge commit)
        \       /
         ->b1->b2

Say i have had a conflict in one file that i fixed in branch while merging master. i fixed it and it now looks nothing like how the file looks in master ( at commit m3). if i merge the branch ( now at commit mb) back into master, git does not complain that there is a conflict. is the file not different? how does it know its not a conflict and it needs to use the file coming from the branch ?

I get that its the right behavior but i am just curious what tells git that the one in branch is the 'right' one.

user993797
  • 115
  • 2
  • 2
  • 10
  • The fixed conflict is merged into master so the conflict is fixed. – dan1st May 31 '21 at 19:47
  • **roughly**, It's a matter of checking the differences that the separate branches introduced against _the last common ancestor_. When you merge master into branch X, when you try to merge X into master, the last common ancestor between both branches would be **master** (if it hasn't moved). So whatever changes you introduced into X will have to be put into master as a result of that merge. – eftshift0 May 31 '21 at 19:52
  • The common ancestor is the last common commit where the file is the same in both branches? so when i did a merge of master into branch did the last common commit change for the file? – user993797 May 31 '21 at 19:59
  • 2
    Your diagrams are inconsistent and make no sense and there is no m3. Please fix the diagrams to clarify the question. Thanks. – matt May 31 '21 at 21:00
  • See also [this question](https://stackoverflow.com/q/44359334/1256452) and [this one](https://stackoverflow.com/q/50567245/1256452) as well. The lack of a conflict *after* merging is a result of the updated merge base, as [matt answers](https://stackoverflow.com/a/67780209/1256452). – torek Jun 01 '21 at 00:31

1 Answers1

2

Thing to know: what is a merge? It is a combination of the changes in both branches since the merge base (ie where the branches "diverged" most recently).

"what tells git that the one in branch is the 'right' one."

That is the whole point of "reverse" merges. Imagine this situation:

 mergebase
     |
A -- B -- C <- master
     \
      X <- branch

At this moment, B is the merge base if you merge either way between the two branches. Assume that both C and X change the same file in such a way as to generate a potential merge conflict. OK, so you merge master into branch and fix the conflict in that file (forming merge commit M in the diagram below). This also moves the merge base to the tip of master (C), in preparation for the upcoming forward merge:

      mergebase
          |
A -- B -- C <- master
     \    \
      X -- M <- branch

Hopefully, when you do then merge branch into master, master is unchanged since the merge base C (at least with respect to this file). Thus master makes no contribution since the merge base, but branch does (the merge commit M has a different version of the file than C does), so only branch contributes to the merge and its version of the file is adopted.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • That makes sense, I did not realize that an activity in the branch ( a merge) would also further the merge base on the source branch ( master). Thanks for taking the time. – user993797 Jun 01 '21 at 03:33