Re: [PATCH 06/11] merge-ort: add implementation of both sides renaming identically

From: Derrick Stolee <stolee@gmail.com>
To: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Cc: Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH 06/11] merge-ort: add implementation of both sides renaming identically
Date: Thu, 10 Dec 2020 22:32:30 -0500	[thread overview]
Message-ID: <fb33f41f-ab00-fcb8-b64f-496c0e0450e7@gmail.com> (raw)
In-Reply-To: <9c79b9f4a096afeef620ff4fc1f85525923e3d02.1607542887.git.gitgitgadget@gmail.com>

On 12/9/2020 2:41 PM, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
> 
> Implement rename/rename(1to1) handling, i.e. both sides of history
> renaming a file but renaming the same way.  This code replaces the
> following from merge-recurisve.c:
> 
>   * all the 1to1 code in process_renames()
>   * the RENAME_ONE_FILE_TO_ONE case of process_entry()
> 
> Also, there is some shared code from merge-recursive.c for multiple
> different rename cases which we will no longer need for this case (or
> other rename cases):
> 
>   * handle_rename_normal()
>   * setup_rename_conflict_info()
> 
> The consolidation of four separate codepaths into one is made possible
> by a change in design: process_renames() tweaks the conflict_info
> entries within opt->priv->paths such that process_entry() can then
> handle all the non-rename conflict types (directory/file, modify/delete,
> etc.) orthogonally.  This means we're much less likely to miss special
> implementation of some kind of combination of conflict types (see
> commits brought in by 66c62eaec6 ("Merge branch 'en/merge-tests'",
> 2020-11-18), especially commit ef52778708 ("merge tests: expect improved
> directory/file conflict handling in ort", 2020-10-26) for more details).
> That, together with letting worktree/index updating be handled
> orthogonally in the merge_switch_to_result() function, dramatically
> simplifies the code for various special rename cases.
> 
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>  merge-ort.c | 21 +++++++++++++++++++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/merge-ort.c b/merge-ort.c
> index faec29db955..085e81196a5 100644
> --- a/merge-ort.c
> +++ b/merge-ort.c
> @@ -647,14 +647,31 @@ static int process_renames(struct merge_options *opt,
>  		    !strcmp(oldpath, renames->queue[i+1]->one->path)) {
>  			/* Handle rename/rename(1to2) or rename/rename(1to1) */
>  			const char *pathnames[3];
> +			struct version_info merged;
> +			struct conflict_info *base, *side1, *side2;
> +			unsigned was_binary_blob = 0;

Since you are adding to the declarations here, I suppose it would be
reasonable to include the 1to2/1to1 split here instead of the previous
patch, if that seems useful to reduce the complexity of that patch.

>  			pathnames[0] = oldpath;
>  			pathnames[1] = newpath;
>  			pathnames[2] = renames->queue[i+1]->two->path;
>
> +			base = strmap_get(&opt->priv->paths, pathnames[0]);
> +			side1 = strmap_get(&opt->priv->paths, pathnames[1]);
> +			side2 = strmap_get(&opt->priv->paths, pathnames[2]);
> +
> +			VERIFY_CI(base);
> +			VERIFY_CI(side1);
> +			VERIFY_CI(side2);
> +
>  			if (!strcmp(pathnames[1], pathnames[2])) {
> -				/* Both sides renamed the same way. */
> -				die("Not yet implemented");
> +				/* Both sides renamed the same way */
> +				assert(side1 == side2);
> +				memcpy(&side1->stages[0], &base->stages[0],
> +				       sizeof(merged));
> +				side1->filemask |= (1 << 0);
> +				/* Mark base as resolved by removal */
> +				base->merged.is_null = 1;
> +				base->merged.clean = 1;

Looks good.

Thanks,
-Stolee