{"thread":{"id":"16833","subject":"Move-delete merge conflict is not displayed using git ls-files --unmerged","startedAt":"2008-12-22T14:29:02Z","lastAt":"2008-12-23T16:20:14Z","messageCount":5,"participants":["Constantine Plotnikov","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"98545","messageId":"85647ef50812220629o46134a70waf159bb6cd6d6e72@mail.gmail.com","threadId":"16833","inReplyTo":null,"subject":"Move-delete merge conflict is not displayed using git ls-files --unmerged","fromName":"Constantine Plotnikov","fromEmail":"constantine.plotnikov@gmail.com","sentAt":"2008-12-22T14:29:02Z","receivedAt":"2008-12-22T14:29:02Z","isPatch":false,"sender":{"key":"constantine.plotnikov@gmail.com","avatar":null},"body":"Lets consider repository state created with the following script (git\nversion 1.6.0.4).\n\nmkdir test-move-delete\ncd test-move-delete\ngit init\necho test1 >file.txt\necho test2 >>file.txt\necho test3 >>file.txt\necho test4 >>file.txt\ngit add file.txt\ngit commit -m \"start\"\ngit checkout -b moved master\ngit mv file.txt copy.txt\ngit commit -m \"moved\"\ngit checkout -b deleted master\ngit rm file.txt\ngit commit -m \"deleted\"\ngit merge moved\n\nThe last merge command fails with move-delete conflict.\n\nCONFLICT (rename/delete): Renamed file.txt->copy.txt in moved and\ndeleted in HEAD\nAutomatic merge failed; fix conflicts and then commit the result.\n\nHowever git ls-files --unmerged does not list any conflict in that\ncase and it is possible to execute git commit command right away\nwithout doing anything with the repository.\n\nI think that if git merge reports the conflicts, such conflicts should\nbe discoverable using git ls-files and prevent commit with resolving\nthe conflict like it is done with modify-delete conflicts.\n\nRegards,\nConstantine\n"},{"id":"98555","messageId":"7v4p0whr7a.fsf@gitster.siamese.dyndns.org","threadId":"16833","inReplyTo":"85647ef50812220629o46134a70waf159bb6cd6d6e72@mail.gmail.com","subject":"Re: Move-delete merge conflict is not displayed using git ls-files --unmerged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-22T20:48:09Z","receivedAt":"2008-12-22T20:48:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Constantine Plotnikov\" <constantine.plotnikov@gmail.com> writes:\n\n> I think that if git merge reports the conflicts, such conflicts should\n> be discoverable using git ls-files and prevent commit with resolving\n> the conflict like it is done with modify-delete conflicts.\n\nYeah, I think so, too.\n"},{"id":"98565","messageId":"alpine.DEB.1.00.0812222308410.30769@pacific.mpi-cbg.de","threadId":"16833","inReplyTo":"7v4p0whr7a.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] merge-recursive: mark rename/delete conflict as unmerged","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-12-22T22:10:20Z","receivedAt":"2008-12-22T22:10:20Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen a file was renamed in one branch, but deleted in the other, one\nshould expect the index to contain an unmerged entry, namely the\ntarget of the rename.  Make it so.\n\nNoticed by Constantine Plotnikov.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n\n\tOn Mon, 22 Dec 2008, Junio C Hamano wrote:\n\n\t> \"Constantine Plotnikov\" <constantine.plotnikov@gmail.com> writes:\n\t> \n\t> > I think that if git merge reports the conflicts, such \n\t> > conflicts should be discoverable using git ls-files and prevent \n\t> > commit with resolving the conflict like it is done with\n\t> > modify-delete conflicts.\n\t> \n\t> Yeah, I think so, too.\n\n\tA test case would have been nice.\n\n merge-recursive.c          |    5 +++++\n t/t6024-recursive-merge.sh |   23 +++++++++++++++++++++++\n 2 files changed, 28 insertions(+), 0 deletions(-)\n\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex a0c804c..69e7152 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -902,6 +902,11 @@ static int process_renames(struct merge_options *o,\n \t\t\t\t       ren1_src, ren1_dst, branch1,\n \t\t\t\t       branch2);\n \t\t\t\tupdate_file(o, 0, ren1->pair->two->sha1, ren1->pair->two->mode, ren1_dst);\n+\t\t\t\tupdate_stages(ren1_dst, NULL,\n+\t\t\t\t\t\tbranch1 == o->branch1 ?\n+\t\t\t\t\t\tren1->pair->two : NULL,\n+\t\t\t\t\t\tbranch1 == o->branch1 ?\n+\t\t\t\t\t\tNULL : ren1->pair->two, 1);\n \t\t\t} else if (!sha_eq(dst_other.sha1, null_sha1)) {\n \t\t\t\tconst char *new_path;\n \t\t\t\tclean_merge = 0;\ndiff --git a/t/t6024-recursive-merge.sh b/t/t6024-recursive-merge.sh\nindex 802d0d0..129fa30 100755\n--- a/t/t6024-recursive-merge.sh\n+++ b/t/t6024-recursive-merge.sh\n@@ -97,4 +97,27 @@ test_expect_success 'refuse to merge binary files' '\n \t\tmerge.err\n '\n \n+test_expect_success 'mark rename/delete as unmerged' '\n+\n+\tgit reset --hard &&\n+\tgit checkout -b delete &&\n+\tgit rm a1 &&\n+\ttest_tick &&\n+\tgit commit -m delete &&\n+\tgit checkout -b rename HEAD^ &&\n+\tgit mv a1 a2\n+\ttest_tick &&\n+\tgit commit -m rename &&\n+\ttest_must_fail git merge delete &&\n+\ttest 1 = $(git ls-files --unmerged | wc -l) &&\n+\tgit rev-parse --verify :2:a2 &&\n+\ttest_must_fail git rev-parse --verify :3:a2 &&\n+\tgit checkout -f delete &&\n+\ttest_must_fail git merge rename &&\n+\ttest 1 = $(git ls-files --unmerged | wc -l) &&\n+\ttest_must_fail git rev-parse --verify :2:a2 &&\n+\tgit rev-parse --verify :3:a2\n+\n+'\n+\n test_done\n-- \n1.6.1.rc3.412.ga72b\n"},{"id":"98568","messageId":"7v7i5rhkix.fsf@gitster.siamese.dyndns.org","threadId":"16833","inReplyTo":"alpine.DEB.1.00.0812222308410.30769@pacific.mpi-cbg.de","subject":"Re: [PATCH] merge-recursive: mark rename/delete conflict as unmerged","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-22T23:12:22Z","receivedAt":"2008-12-22T23:12:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> When a file was renamed in one branch, but deleted in the other, one\n> should expect the index to contain an unmerged entry, namely the\n> target of the rename.  Make it so.\n\nThat was quick, but the surrounding code makes me wonder if other\nif/elseif branches also need similar handling.\n\nFor example, rename/add comes up with a new name that does not exist\nanywhere, and adds both to the index; it is understandable that you need\nto do this when processing a merge with non-zero depth because you need to\nhave a tree as the result, but shouldn't the final zero depth merge just\nuse the original names and leave the results in higher stages?\n"},{"id":"98619","messageId":"alpine.DEB.1.00.0812231716000.30769@pacific.mpi-cbg.de","threadId":"16833","inReplyTo":"7v7i5rhkix.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] merge-recursive: mark rename/delete conflict as unmerged","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-12-23T16:20:14Z","receivedAt":"2008-12-23T16:20:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Dec 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > When a file was renamed in one branch, but deleted in the other, one \n> > should expect the index to contain an unmerged entry, namely the \n> > target of the rename.  Make it so.\n> \n> That was quick, but the surrounding code makes me wonder if other\n> if/elseif branches also need similar handling.\n\nI tried to make sure that the surrounding code also adds unmerged entries, \nbut I have to admit that my focus lay with the bug report at hand.\n\n> For example, rename/add comes up with a new name that does not exist \n> anywhere, and adds both to the index; it is understandable that you need \n> to do this when processing a merge with non-zero depth because you need \n> to have a tree as the result, but shouldn't the final zero depth merge \n> just use the original names and leave the results in higher stages?\n\nHmm.  I think this is a different issue (if you mean the issue that the \nresult might be named differently than expected).\n\nAs for the unmerged entries, no, I do not think we need to do anything \nelse besides calling update_file() and set try_merge = 1.\n\nAfter all, if a file was renamed in one branch, but added directly in \nanother, does it need to conflict?  I'd say no.\n\nCiao,\nDscho\n"}]}