Hi Elijah,

On Tue, 11 Jan 2022, Elijah Newren wrote:

On Mon, Jan 10, 2022 at 9:59 AM Elijah Newren [off-list ref] wrote:

quoted

On Mon, Jan 10, 2022 at 5:49 AM Johannes Schindelin
[off-list ref] wrote:

quoted

...

quoted

quoted

, 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.

Indeed.

What's even worse is the question how to represent that in a web UI, and I
think I'll wait for that to happen (if ever) to give that part of the
design more thought.

Ciao,
Dscho