Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Sat, 4 Jul 2009, Stefan Bucur wrote: > > > > http://pastebin.ca/1483228 > > > > The problem is with the last diff in the file, where the left portion is empty, > > and the right portion contains code which already was marked as merged (common), > > right before the start of the diff. Therefore, the mark at line 127 should > > really have been before line 114. > > > > Is this a bug or I am missing something? > > I suspect (but without the origin files/history I can't verify) that what > happens is that the "successfully merged" code was seen as a fully new > snippet of code (probably due to getting re-indented?), and the other part > of that action on that branch was the removal of the old code. > > That _removal_ is then shown as a conflict against the other branch, which > presumably didn't re-indent things (of course, it could be exactly the > other way around too), and so now you end up having the "conflict" being > seen as "one branch removes this code (empty conflict part), the other one > presumably changed it some way". > > Is that what you wanted? Obviously not. To you, the conflict makes no > sense. You're a human, who tries to understand what wen't wrong, and to > you, the end result of the conflict resolution makes no sense. [...] > - 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. There is also "git mergetool" which runs graphical merge tool of your choice. It can be easier to work with GUI here. And git also supports diff3 conflict merge markers, which shows our and their side, and also the ancestor side; in your case it would make easy to distinguish between 'one side added' and 'other side removed'. You can get it using $ git checkout --conflict=diff3 <file> (where <file> can be '.'). You would need modern git (post 1.6.2 I think) for that. > The right answer is probably some combination of "all of the above". In > the meantime, right now, only the last one is something git itself will > help you with. -- Jakub Narebski Poland ShadeHawk on #git -- 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