more merge features

[Byron]

This PR adds the last remaining features that are required to do all merging in GitButler with gitoxide.

Follow-up of #1659.

Tasks

• add Resolution::CompleteAfterAutoResolution and assure it's easy to learn about this kind of conflict when checking if there was an unresolved conflict or not.
• Fix incorrect rename tracking settings for diff.renames and merge.renames
• Provide a set of index entries as part of the conflict information and a way to apply them to an ancestor index, compare it to what Git produces.
• wire index-creation up in gix

Bring these changes to the downstream and make a release.

Shortcomings

• the apply operation most certainly isn't going to deal with sparse entries correctly, unless the whole index is reproduced from the newly written tree.

Next PR

• A way to resolve conflicts towards using our or their side. Either at conflict time, or post-conflict time, but fully tested as part of baseline expectations. Probably better to make it as part of the merge operation.
  • Note that we still want to record if a conflict occurred, and in case of text-merges we want to know if there would have been a conflict if we wouldn't have auto-resolved it. Lastly, for binary merges, we may assume a conflict, of course.

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.

Research

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

Archive

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.