Re: Wrong file diff for merge conflict

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

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