On Sun, Jul 5, 2009 at 9:43 PM, Linus Torvalds<torvalds@xxxxxxxxxxxxxxxxxxxx> 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 -- 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