3 messages, 3 authors, 2016-06-15 · open the first message on its own page
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:45:39
"Anders Melchiorsen" [off-list ref] writes:
Your patch got rid of the errors and it commits the merged tree. But the working tree is not updated correctly, so the moved file disappears.
Isn't this a long known breakage of D/F conflict check logic in merge-recursive backend?
From: Alex Riesen <hidden>
Date: 2016-06-15 22:45:39
Junio C Hamano, Fri, Nov 14, 2008 01:29:34 +0100:
"Anders Melchiorsen" [off-list ref] writes:quoted
Your patch got rid of the errors and it commits the merged tree. But the working tree is not updated correctly, so the moved file disappears.Isn't this a long known breakage of D/F conflict check logic in merge-recursive backend?
Could be, but there is no conflicting entries in the merged branches. All file names are different and the D/F transition happens completely on one branch. And the patch isn't enough: the file Anders noticed missing is in the index (correctly) but somehow removed from worktree. Which is maybe because it _still_ was a rename: 99% similarity. Well, just "yes | tail -nNN" usually producess very similar data :) Still broken, of course...
From: Anders Melchiorsen <hidden>
Date: 2016-06-15 22:45:39
Alex Riesen wrote:
And the patch isn't enough: the file Anders noticed missing is in the index (correctly) but somehow removed from worktree. Which is maybe because it _still_ was a rename: 99% similarity. Well, just "yes | tail -nNN" usually producess very similar data :)
Maybe reducing the example all the way down to "touch" lost the implicit information that, indeed, it has to be a rename for this to fail. Anders.