Re: Wrong file diff for merge conflict

[Stefan Bucur <stefan.bucur@gmail.com>]

On Sun, Jul 5, 2009 at 9:43 PM, Linus
Torvalds<torvalds@linux-foundation.org> wrote:
>
>
> 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.


Thank you for your suggestions for a better and more efficient merging
experience, as I'm sure they will help me from now on. However, I
think I did not make myself clear: I was not arguing the fact that the
merge result was suboptimal, but the fact that _the generated conflict
file is semantically wrong_. So, to reiterate, we have this git
generated file:

http://pastebin.ca/1483228

Basically, if one would take the common (successfully merged) parts
and keep the "left" parts in the conflict sections, one would obtain
the first branch version of the file (with minor modifications).
Similarly, if one would opt to keep only the "right" parts in the
conflict section, one would obtain the version found in the second
branch before merge.

However, this is _not_ true in my case. If you take the last conflict
section in the file, if you would keep the left part, you would obtain
the correct left branch file, while if you keep the right part, you
would obtain duplicate code (the common code right before + the
disputed part). And that's why I think this is wrong behavior.

Moreover, now I was able to trigger the bug in a way that leads to
_data loss_. You can find here [1] an archive with a simple git
repository with two branches, "a" and "b", right after a merge between
the two, in a conflict state. The conflict file contains code which is
missing data in one of the two diff sides:

http://pastebin.ca/1485051

You can notice, in the first conflict section, that the right brace of
the inner structure is present in the left part, while it is missing
in the right part (feel free to reset the merge and do it again to see
it for yourself). If you would blindly select the right part for
conflict resolution, you would get erroneous code.

Do you still think it is not a bug?

Thank you,
Stefan Bucur


[1] http://terminus.zytor.com/~stefanb/git/testrepo.tgz