Re: [RFC PATCH 0/2] Introduce new merge-tree-ort command

From: Elijah Newren <newren@gmail.com>
Date: Jan 11, 2022, 21:15 UTC
Message-ID: <CABPp-BEQ5BBEgB21hUNBuioOfMry_x2nKOLgY8=v2w8eGXrsyw@mail.gmail.com>
In-Reply-To: <CABPp-BHJvFx0fxobYZ2vauK=KfCLF_7So8xABLjqr9rx4SVy-w@mail.gmail.com>

On Mon, Jan 10, 2022 at 9:59 AM Elijah Newren <newren@gmail.com> wrote:

>
> On Mon, Jan 10, 2022 at 5:49 AM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >

...

Show 14 quoted lines

> >, therefore it expects the resolved conflicts to
> > be in _files_. I don't think that there is a way to reasonably handle
> > symlink target conflicts or directory/file/symlink conflicts, but there
> > might be.
>
> You really need (mode,oid) pairs to be provided by the user.  That
> fixes the executable issue I mentioned above, and makes it clear how
> to handle symlinks and file/symlink conflicts.
>
> directory/file are still handled by providing individual files, but
> ordering traversal becomes really tricky.  The directory/file case
> might even require the pre_resolved_conflicts to be pulled out of that
> loop somehow.  It'd take some investigative work, or some deep
> thought, or both.

I think I came up with a solution to this during my run yesterday, though I haven't tried or tested it. Instead of modifying the loop over plist.items, you instead add a preliminary loop over pre_resolved_conflicts that modifies opt->priv->paths (and add this preliminary loop just before the items from opt->priv->paths are added to plist.items). In that preliminary loop, you need to make sure that (a) any files in pre_resolved_conflicts corresponding to existing _files_ in opt->priv->path result in updating that item's clean & is_null & mode & oid state, (b) any files in pre_resolved_conflicts that correspond to existing _directories_ in opt->priv->path need the value to be expanded to be a conflict_info instead of just a merged_info, you need to set the df_conflict bit, and don't update the merge_info fields but do update the extended conflict_info ones, (c) any new files in pre_resolved_conflicts result in new entries opt->priv->paths, (d) any leading directories of new files in pre_resolved_conflicts are appropriately handled, meaning: (d1) new opt->priv->paths are created if the directory path wasn't in opt->priv->paths before, (d2) a tweak to df_conflict for the directory item if it previously existed in opt->priv->paths but only as a file (possibly also necessitating expanding from a merged_info to a conflict_info), (d3) no-op if the directory already existed in opt->priv->paths and was just a directory (and in this case, you can stop walking the parent directories to the toplevel).

Then, after this preliminary loop that modifies opt->priv->paths, the rest can just proceed as-is.

That should handle new files, new directories, and all directory/file conflicts. Yeah, it's a bunch to look at, but directory/file conflicts are always a bear.