On 2008.09.03 00:50:43 -0700, Junio C Hamano wrote: > 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. OK, so that basically means "if you cherry-pick, you better make sure that you don't have to revert or just get your fine-toothed comb ready when you merge later", right? Any advice on how to deal with such a situation? The actual use case I had was somewhat like this: Some new code got added in commit A on the master branch as it was intended for the next major release. Then it became obvious that it needs to go into a minor release, so it got cherry-picked into the maintainance branch. For some reason that new code then got moved into a different file. That move happened on the maintainance branch (ie. immediate bugfix). And then came the regular merge of the maintainance branch into the master branch, which ended up with the code being duplicated. (Well, actually, it's a two-level maintainance branch setup, but you get the idea...) Of course, in a perfect world the first commit would never have been cherry-picked and would've been originally made on the maintainance branch, and the problem would have never shown up. But that's not the case and I'm not omniscient, so I would have surely missed the problem, if it wasn't for that two-level setup, which for this merge meant that the merge result should have been equal to the branch being merged, so it was easy to spot. Björn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
