Hi Elijah, On Tue, 11 Jan 2022, Elijah Newren wrote: > On Mon, Jan 10, 2022 at 9:59 AM Elijah Newren <newren@xxxxxxxxx> wrote: > > > > On Mon, Jan 10, 2022 at 5:49 AM Johannes Schindelin > > <Johannes.Schindelin@xxxxxx> wrote: > > > > ... > > >, 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
