On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren <newren@xxxxxxxxx> wrote:
> 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.
I presume these are created via insert_stage_data called in
get_renames, when the path entry is not found?
> 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.
It is hard to trace this down, though looking at
3af244caa8 (Cumulative update of merge-recursive in C, 2006-07-27)
may help us reason about it.
How would a bug look like?
>
> Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
> ---
> merge-recursive.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 1d3f8f0d22..52521faf09 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.5.g9567be9905
>
