Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > So is it a bug? Nope. I can pretty much guarantee that it's not a bug.... Without the precise common ancestor version it is hard to tell, but using the "one old version http://pastebin.ca/1483691"; as a base and running diff3 (or merge from RCS suite) yields identical results as ours, so in that sense it is not a bug. > - Tune the zealous merge a bit, and in particular try to avoid the cases > where this happens (as mentioned, in C code, it's often re-indentation > together with trivial lines that match after it). > > This is kind of what the "patience" diff algorithm tries to do: use > primarily non-trivial sequences as the anchors for similarity, and > ignore the trivial ones. We have a "--patience" switch to "git diff", > maybe we could tune the three-way merge somehow similarly. Hmm. I have to think about this a bit. > - Don't rely so heavily on just the traditional three-way merge result. > > This is what I personally do. The trivial 3-way merge result is > wondeful for the truly trivial merges, when it gives trivial results > that are easy to fix up. But let's face it, the traditional 3-way merge > result just sucks for anything more complicated. When you have an empty > side on one of the conflicts, is that because the other side added > everything, or is it because oen side removed it? Or is it, like in > this case, simply because trivially similar lines got the whole diff > confused about which parts didn't change at all? > > The good news is that git does have a few nice merge tools. One is > "git diff", which actually shows way more than the trivial three-way > end result, in that you can diff against either side, and by default it > does that fairly complex "diff against both sides" thing that is also > quite useful once you get used to it. > > Another is "gitk --merge [filename]" which is wonderful as a tool to > see what both sides actually did, to figure out what the intent of both > branches were when the three-way merge result is just noise. Two other are "git log --merge -p" and "git checkout --conflicts=diff3". > The right answer is probably some combination of "all of the above". In > the meantime, right now, only the last one is somethign git itself will > help you with. -- 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