So there is master that goes
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.
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
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
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