tree merge with tree-related auto-resolution

[Byron]

Make it possible to resolve tree-conflicts with ours while making it possible to notice that a conflict would otherwise have occurred.

The idea is that one wants to produce a suitable tree while noticing that a conflict would have occurred if we wouldn't have resolved it.

Follow-up of #1661.

Tasks

• design API so that current ancestor usecase and ours is covered
• first simple tests
• work through all remaining cases in the test-suite, each of them must be resolved to ours and ancestors with A-B and B-A order.
• add support for tree-conflict resolution to gix.
• add support for to gix merge tree/commit, start sharing settings in clap as well.
• complex tests that replace tree with non-tree (nested) and non-tree with tree. The latter probably needs special care (see whatever/empty in simple)
• clear out todo!() and dbg!
• (gitoxide issue, which takes url::password() directly even though it's percent-encoded)
• merge has to turn off empty-oid rename tracking, but only when finding individual files (directory tracking should still work)
  • rename-within-rename - needs forced resolution tests

Implementation Notes

• We don't optimise for the ancestor case, so it's not always as good as it can possibly be, fortunately in what I would call 'niche' situations. In practice, it's only used for merging virtual merge bases.
• The system can be thrown off if very unlikely renames are found where Git doesn't find it at all. Sometimes this leads to unexpected results and should be fixed by improving rename tracking to be closer to Git, taking names into consideration and having candidates.
• merge.directoryRenames isn't implemented, even though Git has a handle for that. We could respect the setting by deciding what should be a conflict, even though right now we always track directory renames.

Possible Tasks

• Submodule merges are also possible! Maybe outscope it though! libgit2 also doesn't try it.
• textconv with context, see this gist for details.
  • There seem to be different 'tiers' of tools, some don't get GIT_DIR set, others do.
  • It also seems that diff-programs get too much context right now, but that depends on how much is passed to them by the caller as gix-command::Context.
• How to model virtual-merge-bases? Can be none or many, user should have control over how this is done.
• Actual tree-based merging
• Make blob-merge based conflict handling possible in the tree merge from gix at least. - not needed for now
• consider finding a way to more clearly say what happened, maybe with some additional explanation so it's more of a drill-down way of working, instead of a super-enum with a lot of very similar cases.

Archive

Previous Research (index creation)

• record_conflicted_entries() sets the index to match what was recorded.
  • This happens right after checking out the new tree, which alters the index to match it and does all the safety-related work. The key here is that only the conflicted entries matter.
• Git checks out the tree directly, which not only changes the working tree, but also adjusts the existing index efficiently by leaving the metadata uptodate. This is something we should offer as well so the index-adjustment would be done right after, with the index being written just once.
  • GB would have to checkout the tree-id then, load the index, apply the conflicting paths, to finally write the index a second time. This can be optimized later once gitoxide can checkout a tree as well (while keeping the index in memory).
• checkout() by tree-id, with auto-updates to the index, in-memory.

Everything is about MergeORT.

ability to re-use object caches of a repo that has seen the base-tree already, but overall, who knows*

• merge-options passed with -X ours for instance don't affect tree-related auto-resolutions, just the ones related to content. This could be implemented when there is demand though.
• it uses an empty tree if there is no merge-base - we must allow the same.
• it allows for multiple merge-bases, creating a virtual one by merging all merge-bases together using the same algorithm, recursively.
• merges can have conflicts without a individual files being involved, for instance when directory renames clash
• Note that merge-ORT cannot properly handle renames within renamed directories, ending up with the source of the subdir-rename still present.

❯ git ls-tree -r $(git merge-tree main feat)
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    a
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    git-sec-renamed/2
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    git-sec-renamed/7
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    git-sec-renamed/subdir/6
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    git-sec/subdir-renamed/6
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    git-sequencer
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    gix/5
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    h

• Must make sure that possible types of conflicts are properly communicated, to not degenerate information
• It puts conflict-markers in the blobs of the result tree, with annotations to provide additional context
• Need resolution configuration, see git2::MergeOptions.
• data stored by path, and is interned in the map to allow pointer-based comparisons
  • merge-info with everything one needs to know, also related to renames
  • or conflict information
  • it uses a memory-pool/arena to get memory for many paths all at once (and also release it like that)
• paths start out as conflicted, and then can later be changed to non-conflicting if a content-based merged succeeded.
  • If it remains conflicts, the meta-data is used to produce an 'as merged as possible' version with conflict markers that can be checked out to the working tree.
• hunks can partially overlap, but can also be resolved line-by line to some extend.