{"thread":{"id":"19282","subject":"[PATCH] Add a reminder test case for a merge with F/D transition","startedAt":"2009-05-11T09:42:17Z","lastAt":"2009-05-20T22:09:57Z","messageCount":8,"participants":["Alex Riesen","Junio C Hamano","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"113528","messageId":"81b0412b0905110242u3624f0eeyc0dc9b2b987bfa2b@mail.gmail.com","threadId":"19282","inReplyTo":null,"subject":"[PATCH] Add a reminder test case for a merge with F/D transition","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-05-11T09:42:17Z","receivedAt":"2009-05-11T09:42:17Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"The problem is that if a file was replaced with a directory containing\nanother file with the same content and mode, an attempt to merge it\nwith a branch descended from a commit before this F->D transition will\ncause merge-recursive to break. It breaks even if there were no\nconflicting changes on that other branch.\n\nOriginally reported by Anders Melchiorsen.\n\nSigned-off-by: Alex Riesen \n---\n\n2009/5/11 Johannes Schindelin :\n>\n> Maybe you can turn this into a patch adding a test (with\n> test_expect_failure to mark it as a bug)?  This would make debugging a lot\n> easier, as a non-installed Git could be tested.\n\nHere.\n\n t/t6020-merge-df.sh | 23 +++++++++++++++++++++++\n 1 files changed, 23 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t6020-merge-df.sh b/t/t6020-merge-df.sh\nindex a19d49d..b62b52a 100755\n--- a/t/t6020-merge-df.sh\n+++ b/t/t6020-merge-df.sh\n@@ -22,4 +22,27 @@ git commit -m \"File: dir\"'\n\n test_expect_code 1 'Merge with d/f conflicts' 'git merge \"merge msg\" B master'\n\n+test_expect_failure 'F/D conflict' '\n+\tgit reset --hard &&\n+\tgit checkout master &&\n+\trm .git/index &&\n+\n+\tmkdir before &&\n+\techo FILE >before/one &&\n+\techo FILE >after &&\n+\tgit add . &&\n+\tgit commit -mfirst &&\n+\n+\trm -f after &&\n+\tgit mv before after &&\n+\tgit commit -mmove &&\n+\n+\tgit checkout -b para HEAD^ &&\n+\techo COMPLETELY ANOTHER FILE >another &&\n+\tgit add . &&\n+\tgit commit -mpara &&\n+\n+\tgit merge master\n+'\n+\n test_done\n-- \n1.6.3.28.ga852b\n\n\nFrom 05433a6f896c40e4a039815d86613d7e351ef0da Mon Sep 17 00:00:00 2001\nFrom: Alex Riesen \nDate: Mon, 11 May 2009 11:31:42 +0200\nSubject: [PATCH] Add a reminder test case for a merge with F/D transition\n\nThe problem is that if a file was replaced with a directory containing\nanother file with the same content and mode, an attempt to merge it\nwith a branch descended from a commit before this F->D transition will\ncause merge-recursive to break. It breaks even if there were no\nconflicting changes on that other branch.\n\nOriginally reported by Anders Melchiorsen.\n\nSigned-off-by: Alex Riesen \n---\n t/t6020-merge-df.sh | 23 +++++++++++++++++++++++\n 1 files changed, 23 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t6020-merge-df.sh b/t/t6020-merge-df.sh\nindex a19d49d..b62b52a 100755\n--- a/t/t6020-merge-df.sh\n+++ b/t/t6020-merge-df.sh\n@@ -22,4 +22,27 @@ git commit -m \"File: dir\"'\n \n test_expect_code 1 'Merge with d/f conflicts' 'git merge \"merge msg\" B master'\n \n+test_expect_failure 'F/D conflict' '\n+\tgit reset --hard &&\n+\tgit checkout master &&\n+\trm .git/index &&\n+\n+\tmkdir before &&\n+\techo FILE >before/one &&\n+\techo FILE >after &&\n+\tgit add . &&\n+\tgit commit -mfirst &&\n+\n+\trm -f after &&\n+\tgit mv before after &&\n+\tgit commit -mmove &&\n+\n+\tgit checkout -b para HEAD^ &&\n+\techo COMPLETELY ANOTHER FILE >another &&\n+\tgit add . &&\n+\tgit commit -mpara &&\n+\n+\tgit merge master\n+'\n+\n test_done\n-- \n1.6.3.28.ga852b\n\n"},{"id":"113569","messageId":"20090511192536.GA1485@blimp.localdomain","threadId":"19282","inReplyTo":"81b0412b0905110242u3624f0eeyc0dc9b2b987bfa2b@mail.gmail.com","subject":"[PATCH] Fix for a merge where a branch has an F->D transition","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-05-11T19:25:36Z","receivedAt":"2009-05-11T19:25:36Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Some path names which transitioned from file to a directory were not\nupdated in the final part of the merge (loop around unmerged entries in\nmerge_trees), because the branch in process_renames which filtered out\nupdates for the files with the same content (\"merged same as existing\")\nhas left the rename entry in processed state. In this case, the\nprocessing cannot be finished at the process_renames phase (because\nthe old file still blocks creation of directory where new files should\nappear), and must be postponed until the update_entry phase.\n\nSigned-off-by: Alex Riesen \n---\n\nAlex Riesen, Mon, May 11, 2009 11:42:17 +0200:\n> The problem is that if a file was replaced with a directory containing\n> another file with the same content and mode, an attempt to merge it\n> with a branch descended from a commit before this F->D transition will\n> cause merge-recursive to break. It breaks even if there were no\n> conflicting changes on that other branch.\n> \n> 2009/5/11 Johannes Schindelin :\n> >\n> > Maybe you can turn this into a patch adding a test (with\n> > test_expect_failure to mark it as a bug)?  This would make debugging a lot\n> > easier, as a non-installed Git could be tested.\n> \n> Here.\n> \n> t/t6020-merge-df.sh | 23 +++++++++++++++++++++++\n> 1 files changed, 23 insertions(+), 0 deletions(-)\n> \n\nFrankly, I'm not really sure. The solution came largely ... empirical\nway. IOW, I tried more or less random things which looked like they\nshould fix the problem. So a review is very much appreciated. Please.\n\n merge-recursive.c | 5 +++--\n 1 files changed, 3 insertions(+), 2 deletions(-)\n\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex a3721ef..3c5420b 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -980,14 +980,15 @@ static int process_renames(struct merge_options *o,\n \n \t\t\t\tif (mfi.clean &&\n \t\t\t\t sha_eq(mfi.sha, ren1->pair->two->sha1) &&\n-\t\t\t\t mfi.mode == ren1->pair->two->mode)\n+\t\t\t\t mfi.mode == ren1->pair->two->mode) {\n \t\t\t\t\t/*\n \t\t\t\t\t * This messaged is part of\n \t\t\t\t\t * t6022 test. If you change\n \t\t\t\t\t * it update the test too.\n \t\t\t\t\t */\n \t\t\t\t\toutput(o, 3, \"Skipped %s (merged same as existing)\", ren1_dst);\n-\t\t\t\telse {\n+\t\t\t\t\tren1->dst_entry->processed = 0;\n+\t\t\t\t} else {\n \t\t\t\t\tif (mfi.merge || !mfi.clean)\n \t\t\t\t\t\toutput(o, 1, \"Renaming %s => %s\", ren1_src, ren1_dst);\n \t\t\t\t\tif (mfi.merge)\n-- \n1.6.3.28.ga852b\n"},{"id":"113724","messageId":"7v63g57ce4.fsf@alter.siamese.dyndns.org","threadId":"19282","inReplyTo":"20090511192536.GA1485@blimp.localdomain","subject":"Re: [PATCH] Fix for a merge where a branch has an F->D transition","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-13T06:19:47Z","receivedAt":"2009-05-13T06:19:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> Frankly, I'm not really sure. The solution came largely ... empirical\n> way. IOW, I tried more or less random things which looked like they\n> should fix the problem. So a review is very much appreciated. Please.\n\nI've always thought that D/F conflict logic in merge-recursive is placed\nat the wrong processing phase. IIRC, it enumerates potential D/F\nconflicting paths before even attempting to process renames, and it is\neasy to miss a path that was previously file going away as the result of a\nclean merge (in which case it is ok to have a directory there as the\nresult of a merge for other paths). This breakage could be a small\nexample of it.\n\nRegardless, I think your patch is a reasonable fix to go to the\nmaintenance track. Thanks for looking into it.\n\n> merge-recursive.c | 5 +++--\n> 1 files changed, 3 insertions(+), 2 deletions(-)\n>\n> diff --git a/merge-recursive.c b/merge-recursive.c\n> index a3721ef..3c5420b 100644\n> --- a/merge-recursive.c\n> +++ b/merge-recursive.c\n> @@ -980,14 +980,15 @@ static int process_renames(struct merge_options *o,\n> \n> \t\t\t\tif (mfi.clean &&\n> \t\t\t\t sha_eq(mfi.sha, ren1->pair->two->sha1) &&\n> -\t\t\t\t mfi.mode == ren1->pair->two->mode)\n> +\t\t\t\t mfi.mode == ren1->pair->two->mode) {\n> \t\t\t\t\t/*\n> \t\t\t\t\t * This messaged is part of\n> \t\t\t\t\t * t6022 test. If you change\n> \t\t\t\t\t * it update the test too.\n> \t\t\t\t\t */\n> \t\t\t\t\toutput(o, 3, \"Skipped %s (merged same as existing)\", ren1_dst);\n> -\t\t\t\telse {\n> +\t\t\t\t\tren1->dst_entry->processed = 0;\n> +\t\t\t\t} else {\n> \t\t\t\t\tif (mfi.merge || !mfi.clean)\n> \t\t\t\t\t\toutput(o, 1, \"Renaming %s => %s\", ren1_src, ren1_dst);\n> \t\t\t\t\tif (mfi.merge)\n> -- \n> 1.6.3.28.ga852b\n"},{"id":"113725","messageId":"81b0412b0905122338q774454cj65edfde3d73948e3@mail.gmail.com","threadId":"19282","inReplyTo":"7v63g57ce4.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Fix for a merge where a branch has an F->D transition","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-05-13T06:38:53Z","receivedAt":"2009-05-13T06:38:53Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2009/5/13 Junio C Hamano :\n> Alex Riesen writes:\n>> Frankly, I'm not really sure. The solution came largely ... empirical\n>> way. IOW, I tried more or less random things which looked like they\n>> should fix the problem. So a review is very much appreciated. Please.\n>\n> I've always thought that D/F conflict logic in merge-recursive is placed\n> at the wrong processing phase.  IIRC, it enumerates potential D/F\n> conflicting paths before even attempting to process renames, and it is\n> easy to miss a path that was previously file going away as the result of a\n> clean merge (in which case it is ok to have a directory there as the\n> result of a merge for other paths).  This breakage could be a small\n> example of it.\n>\n> Regardless, I think your patch is a reasonable fix to go to the\n> maintenance track.  Thanks for looking into it.\n\nI'm afraid the fix is not that simple: the \"if\" branch where the change\nis placed supposed to prevent updating files in the working tree\nwhich already have the same content as the merge's output.\nMy change may force them to be updated regardless. I think...\nJohannes, you know this area the best, could you please have\na look?\n"},{"id":"113757","messageId":"alpine.DEB.1.00.0905131159180.5046@intel-tinevez-2-302","threadId":"19282","inReplyTo":"81b0412b0905122338q774454cj65edfde3d73948e3@mail.gmail.com","subject":"Re: [PATCH] Fix for a merge where a branch has an F->D transition","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-13T09:59:29Z","receivedAt":"2009-05-13T09:59:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 May 2009, Alex Riesen wrote:\n\n> 2009/5/13 Junio C Hamano :\n> > Alex Riesen writes:\n> >> Frankly, I'm not really sure. The solution came largely ... empirical\n> >> way. IOW, I tried more or less random things which looked like they\n> >> should fix the problem. So a review is very much appreciated. Please.\n> >\n> > I've always thought that D/F conflict logic in merge-recursive is placed\n> > at the wrong processing phase.  IIRC, it enumerates potential D/F\n> > conflicting paths before even attempting to process renames, and it is\n> > easy to miss a path that was previously file going away as the result of a\n> > clean merge (in which case it is ok to have a directory there as the\n> > result of a merge for other paths).  This breakage could be a small\n> > example of it.\n> >\n> > Regardless, I think your patch is a reasonable fix to go to the\n> > maintenance track.  Thanks for looking into it.\n> \n> I'm afraid the fix is not that simple: the \"if\" branch where the change\n> is placed supposed to prevent updating files in the working tree\n> which already have the same content as the merge's output.\n> My change may force them to be updated regardless. I think...\n> Johannes, you know this area the best, could you please have\n> a look?\n\nSorry, no time at the moment...\n\nCiao,\nDscho\n"},{"id":"113773","messageId":"81b0412b0905130433x6aa780cbt61d99e9f3d0f2720@mail.gmail.com","threadId":"19282","inReplyTo":"alpine.DEB.1.00.0905131159180.5046@intel-tinevez-2-302","subject":"Re: [PATCH] Fix for a merge where a branch has an F->D transition","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-05-13T11:33:33Z","receivedAt":"2009-05-13T11:33:33Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2009/5/13 Johannes Schindelin :\n> On Wed, 13 May 2009, Alex Riesen wrote:\n>> 2009/5/13 Junio C Hamano :\n>> > Alex Riesen writes:\n>> >> Frankly, I'm not really sure. The solution came largely ... empirical\n>> >> way. IOW, I tried more or less random things which looked like they\n>> >> should fix the problem. So a review is very much appreciated. Please.\n>> >\n>> > I've always thought that D/F conflict logic in merge-recursive is placed\n>> > at the wrong processing phase.  IIRC, it enumerates potential D/F\n>> > conflicting paths before even attempting to process renames, and it is\n>> > easy to miss a path that was previously file going away as the result of a\n>> > clean merge (in which case it is ok to have a directory there as the\n>> > result of a merge for other paths).  This breakage could be a small\n>> > example of it.\n>> >\n>> > Regardless, I think your patch is a reasonable fix to go to the\n>> > maintenance track.  Thanks for looking into it.\n>>\n>> I'm afraid the fix is not that simple: the \"if\" branch where the change\n>> is placed supposed to prevent updating files in the working tree\n>> which already have the same content as the merge's output.\n>> My change may force them to be updated regardless. I think...\n>> Johannes, you know this area the best, could you please have\n>> a look?\n>\n> Sorry, no time at the moment...\n>\n\nMaybe the patch could live on master or next for while? Many people\ntrack master, so a performance degradation, if it happens, will be noticed.\nAnd with master (or even better - next) we have an auditory which is at\nleast capable to complain.\n"},{"id":"114334","messageId":"alpine.DEB.1.00.0905201228040.16461@intel-tinevez-2-302","threadId":"19282","inReplyTo":"20090511192536.GA1485@blimp.localdomain","subject":"Re: [PATCH] Fix for a merge where a branch has an F->D transition","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-20T10:34:52Z","receivedAt":"2009-05-20T10:34:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 11 May 2009, Alex Riesen wrote:\n\n> Some path names which transitioned from file to a directory were not\n> updated in the final part of the merge (loop around unmerged entries in\n> merge_trees), because the branch in process_renames which filtered out\n> updates for the files with the same content (\"merged same as existing\")\n> has left the rename entry in processed state. In this case, the\n> processing cannot be finished at the process_renames phase (because\n> the old file still blocks creation of directory where new files should\n> appear), and must be postponed until the update_entry phase.\n\nI know that as a German, I am supposed to like long sentences and crowded \nparagraphs. Maybe I am not that German after all.\n\n> Frankly, I'm not really sure. The solution came largely ... empirical \n> way. IOW, I tried more or less random things which looked like they \n> should fix the problem.\n\nThis does not give me the cozy feeling I need to review a patch. After \nall, I do not want to do all the work that should be done by the patch \nauthor, but I just want to put in my knowledge to verify that the patch \nis correct.\n\nBut as you asked me explicitely...\n\n> diff --git a/merge-recursive.c b/merge-recursive.c\n> index a3721ef..3c5420b 100644\n> --- a/merge-recursive.c\n> +++ b/merge-recursive.c\n> @@ -980,14 +980,15 @@ static int process_renames(struct merge_options *o,\n> \n> \t\t\t\tif (mfi.clean &&\n> \t\t\t\t sha_eq(mfi.sha, ren1->pair->two->sha1) &&\n> -\t\t\t\t mfi.mode == ren1->pair->two->mode)\n> +\t\t\t\t mfi.mode == ren1->pair->two->mode) {\n> \t\t\t\t\t/*\n> \t\t\t\t\t * This messaged is part of\n> \t\t\t\t\t * t6022 test. If you change\n> \t\t\t\t\t * it update the test too.\n> \t\t\t\t\t */\n> \t\t\t\t\toutput(o, 3, \"Skipped %s (merged same as existing)\", ren1_dst);\n> -\t\t\t\telse {\n> +\t\t\t\t\tren1->dst_entry->processed = 0;\n> +\t\t\t\t} else {\n\nSo basically, you say that a dst_entry has not been processed, when it \n_has_ been? That cannot be correct...\n\nCiao,\nDscho\n"},{"id":"114373","messageId":"81b0412b0905201509o3db682dm9a667210a60b2d24@mail.gmail.com","threadId":"19282","inReplyTo":"alpine.DEB.1.00.0905201228040.16461@intel-tinevez-2-302","subject":"Re: [PATCH] Fix for a merge where a branch has an F->D transition","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-05-20T22:09:57Z","receivedAt":"2009-05-20T22:09:57Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2009/5/20 Johannes Schindelin :\n> On Mon, 11 May 2009, Alex Riesen wrote:\n>\n>> Some path names which transitioned from file to a directory were not\n>> updated in the final part of the merge (loop around unmerged entries in\n>> merge_trees), because the branch in process_renames which filtered out\n>> updates for the files with the same content (\"merged same as existing\")\n>> has left the rename entry in processed state. In this case, the\n>> processing cannot be finished at the process_renames phase (because\n>> the old file still blocks creation of directory where new files should\n>> appear), and must be postponed until the update_entry phase.\n>\n> I know that as a German, I am supposed to like long sentences and crowded\n> paragraphs.  Maybe I am not that German after all.\n>\n\nWill be shortened.\n\n>> diff --git a/merge-recursive.c b/merge-recursive.c\n>> index a3721ef..3c5420b 100644\n>> --- a/merge-recursive.c\n>> +++ b/merge-recursive.c\n>> @@ -980,14 +980,15 @@ static int process_renames(struct merge_options *o,\n>>\n>>                               if (mfi.clean &&\n>>                                   sha_eq(mfi.sha, ren1->pair->two->sha1) &&\n>> -                                 mfi.mode == ren1->pair->two->mode)\n>> +                                 mfi.mode == ren1->pair->two->mode) {\n>>                                       /*\n>>                                        * This messaged is part of\n>>                                        * t6022 test. If you change\n>>                                        * it update the test too.\n>>                                        */\n>>                                       output(o, 3, \"Skipped %s (merged same as existing)\", ren1_dst);\n>> -                             else {\n>> +                                     ren1->dst_entry->processed = 0;\n>> +                             } else {\n>\n> So basically, you say that a dst_entry has not been processed, when it\n> _has_ been?  That cannot be correct...\n>\n\nMy feeling exactly. I'm afraid I just zeroed the effect of the branch\nwhich should avoid rewriting of files with known same content.\nIt's just that the code has grown a little confusing...\nI'm still thinking about how to avoid unneeded rewrites of the files\nwith same content under same name.\n"}]}