Re: [PATCH 4/4] merge-recursive: Avoid showing conflicts with merge branch before HEAD

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> The correct order usually comes naturally and for free, but with renames
> we often have data in the form {rename_branch, other_branch}, and
> working relative to the rename first (e.g. for rename/add) is more
> convenient elsewhere in the code.  Address the slight impedance
> mismatch by having some functions re-call themselves with flipped
> arguments when the branch order is reversed.

I've never noticed or felt disturbed myself, but thanks for this
level of attention to the detail.

> @@ -228,7 +228,26 @@ static inline void setup_rename_conflict_info(enum rename_type rename_type,
>  					      struct stage_data *src_entry1,
>  					      struct stage_data *src_entry2)
>  {
> -	struct rename_conflict_info *ci = xcalloc(1, sizeof(struct rename_conflict_info));
> +	struct rename_conflict_info *ci;
> +
> +	/*
> +	 * When we have two renames involved, it's easiest to get the
> +	 * correct things into stage 2 and 3, and to make sure that the
> +	 * content merge puts HEAD before the other branch if we just
> +	 * ensure that branch1 == o->branch1.  So, simply flip arguments
> +	 * around if we don't have that.
> +	 */
> +	if (dst_entry2 && branch1 != o->branch1) {
> +		setup_rename_conflict_info(rename_type,
> +					   pair2,      pair1,
> +					   branch2,    branch1,
> +					   dst_entry2, dst_entry1,
> +					   o,
> +					   src_entry2, src_entry1);
> +		return;
> +	}

;-)