{"thread":{"id":"24803","subject":"[PATCH] merge-recursive: Avoid excessive output for and reprocessing of renames","startedAt":"2010-08-20T12:55:40Z","lastAt":"2010-08-20T12:55:40Z","messageCount":1,"participants":["Elijah Newren"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"148555","messageId":"1282308940-3527-1-git-send-email-newren@gmail.com","threadId":"24803","inReplyTo":null,"subject":"[PATCH] merge-recursive: Avoid excessive output for and reprocessing of renames","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2010-08-20T12:55:40Z","receivedAt":"2010-08-20T12:55:40Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"In 5a2580d (merge_recursive: Fix renames across paths below D/F conflicts\n2010-07-09) and ae74548 (merge-recursive: Fix multiple file rename across\nD/F conflict 2010-08-17), renames across D/F conflicts were fixed by\nmaking process_renames() consider as unprocessed renames whose dst_entry\n\"still\" had higher stage entries.  The assumption was that those higher\nstage entries would have been cleared out of dst_entry by that point in\ncases where the conflict could be resolved (normal renames with no D/F\nconflicts).  That is not the case -- higher stage entries will remain in\nall cases.\n\nFix this by checking for higher stage entries corresponding to D/F\nconflicts, namely that stages 2 and 3 have exactly one nonzero mode between\nthem.  The nonzero mode stage corresponds to a file at the path, while the\nstage with a zero mode will correspond to a directory at that path (since\nrename/delete conflicts will have already been handled before this codepath\nis reached.)\n\nSigned-off-by: Elijah Newren <newren@gmail.com>\n---\nWhat a mess, sorry for flubbing up the D/F series so badly and the need\nfor so many fixups after it already hit next.  I hope this finally fixes\nthings and that there's no more embarrasing bugs (or even\nnon-embarrasing ones).  Also, it looks like Alex was right about this\n(http://article.gmane.org/gmane.comp.version-control.git/149948), though\nI just didn't quite understand him at the time.  \n\n merge-recursive.c |    8 ++------\n 1 files changed, 2 insertions(+), 6 deletions(-)\n\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex a3fc443..aadd48c 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -1020,7 +1020,6 @@ static int process_renames(struct merge_options *o,\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\tint i;\n \t\t\t\t\t/*\n \t\t\t\t\t * This message is part of\n \t\t\t\t\t * t6022 test. If you change\n@@ -1032,12 +1031,9 @@ static int process_renames(struct merge_options *o,\n \t\t\t\t\t * in the index (e.g. due to a D/F\n \t\t\t\t\t * conflict) that need to be resolved.\n \t\t\t\t\t */\n-\t\t\t\t\tfor (i = 1; i <= 3; i++) {\n-\t\t\t\t\t\tif (!ren1->dst_entry->stages[i].mode)\n-\t\t\t\t\t\t\tcontinue;\n+\t\t\t\t\tif (!ren1->dst_entry->stages[2].mode !=\n+\t\t\t\t\t    !ren1->dst_entry->stages[3].mode)\n \t\t\t\t\t\tren1->dst_entry->processed = 0;\n-\t\t\t\t\t\tbreak;\n-\t\t\t\t\t}\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-- \n1.7.2.1.365.gf72e17\n"}]}