Issue
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.
Solution
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.
Answered By – matt
This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0