From: Ittay Dror Date: Wed, 03 Sep 2008 09:19:57 GMT Subject: Re: Merge seems to get confused by (reverted) cherry-picks Message-ID: <48BE56BD.6050805@gmail.com> In-Reply-To: <7vprnld5ws.fsf@gitster.siamese.dyndns.org> Note: codeville tried to implement a merge algorithm that considers the history to decide what the user wants to do: http://revctrl.org/PreciseCodevilleMerge. Maybe worth while exploring? Ittay Junio C Hamano wrote: > Björn Steinbrink writes: > > >> "git merge" produces a (IMHO) wrong result, when a commit from the >> branch that is to be merged in was cherry-picked into the current branch >> and later reverted on the original branch. Basically ignoring the >> revert. >> > > There are a few issues around 3-way merge. > > One thing is, what happened in between the common ancestor and the final > results on histories before you initiate the merges does not matter. When > doing a 3-way merge, you look only at three endpoints: your final state, > their final state and the common ancestor between the two. > > Your history looks like this: > > 123a456 > 3-----------? > / / > / / > 0-----1-----2 > 123456 123456 > > During the development between 0..2, your undecision might have caused the > contents of the file fluctuate back and forth many number of times, but in > the end result, you (the one who went 0..1..2) decided that for your > development, you do not have to change the contents of that path. The > path might have been a xyzzy.h file, and you once added an extern decl of > a function because you thought a function in xyzzy.c might be needed by > another file frotz.c, but it turned out that the function can stay private > and you removed that extern decl from xyzzy.h and ended up in the same > state. > > But the other person who built the history 0..3 decided that having the > change is better than not having it. Perhaps his code does use the > function from some other place and needs an extern. > > You are merging the two histories, which means by definition you trust > your decision and the other guys decision with equal weight. And here is > another thing. > > When you compare the path in question at 0 and 2, you see they are > identical. And you are interpreting that "I say they MUST STAY THE SAME, > while they say they want to change it some way, that is a conflict". > > But in 3-way merge context, you do not interpret the fact that something > is identical between 0..2 as "they MUST STAY THE SAME". Instead, you read > it as "My history does not care what happens to that path -- if the other > guy wants to change it, I'll happily take it." > > Note. I am not claiming that the above interpretation will always > match what you would expect. I am just explaining how the underlying > concept of 3-way merge works in general. If you think about it in a > realistic context, such as the "extern in xyzzy.h you did not need to > add but the other guy needed to have", you'll realize that more often > than not, "I do not care and let the other guy decide" interpretation > results in a more useful result. > > That essentially boils down to three rules: > > (0) If both of you did not change anything, the final result won't have > any change (obvious); > > (1) If you decided you do not have a need to change a path, but the other > one saw a need, you take the change; > > (2) If you and the other one both wanted to change a path but in a > different way, you need to merge at the contents level. > > And you are seeing rule (1) in action. > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- Ittay Dror Tikal Tikal Project -- -- Ittay Dror