Re: Wrong file diff for merge conflict

> 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.