[PATCH v2 02/33] merge-recursive: fix logic ordering issue

From: Elijah Newren <newren@gmail.com>
Date: Nov 20, 2017, 22:01 UTC
Message-ID: <20171120220209.15111-3-newren@gmail.com>
In-Reply-To: <20171120220209.15111-1-newren@gmail.com>

merge_trees() did a variety of work, including:
  * Calling get_unmerged() to get unmerged entries
  * Calling record_df_conflict_files() with all unmerged entries to
    do some work to ensure we could handle D/F conflicts correctly
  * Calling get_renames() to check for renames.

An easily overlooked issue is that get_renames() can create more unmerged entries and add them to the list, which have the possibility of being involved in D/F conflicts. So the call to record_df_conflict_files() should really be moved after all the rename detection. I didn't come up with any testcases demonstrating any bugs with the old ordering, but I suspect there were some for both normal renames and for directory renames. Fix the ordering.

Signed-off-by: Elijah Newren <newren@gmail.com>
---
 merge-recursive.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index b48b15a6fd..944f938ec8 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1981,10 +1981,10 @@ int merge_trees(struct merge_options *o,
 		get_files_dirs(o, merge);
 
 		entries = get_unmerged();
-		record_df_conflict_files(o, entries);
 		re_head  = get_renames(o, head, common, head, merge, entries);
 		re_merge = get_renames(o, merge, common, head, merge, entries);
 		clean = process_renames(o, re_head, re_merge);
+		record_df_conflict_files(o, entries);
 		if (clean < 0)
 			goto cleanup;
 		for (i = entries->nr-1; 0 <= i; i--) {

-- 
2.15.0.309.g00c152f825