Skip to content

Commit 6c8647d

Browse files
newrengitster
authored andcommitted
merge-recursive: fix logic ordering issue
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. Reviewed-By: Stefan Beller <[email protected]> Signed-off-by: Elijah Newren <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 7c5585f commit 6c8647d

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

merge-recursive.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1989,10 +1989,10 @@ int merge_trees(struct merge_options *o,
19891989
get_files_dirs(o, merge);
19901990

19911991
entries = get_unmerged();
1992-
record_df_conflict_files(o, entries);
19931992
re_head = get_renames(o, head, common, head, merge, entries);
19941993
re_merge = get_renames(o, merge, common, head, merge, entries);
19951994
clean = process_renames(o, re_head, re_merge);
1995+
record_df_conflict_files(o, entries);
19961996
if (clean < 0)
19971997
goto cleanup;
19981998
for (i = entries->nr-1; 0 <= i; i--) {

0 commit comments

Comments
 (0)