Skip to content

merge-base octopus#1659

Merged
Sebastian Thiel (Byron) merged 2 commits into
mainfrom
merge
Nov 7, 2024
Merged

merge-base octopus#1659
Sebastian Thiel (Byron) merged 2 commits into
mainfrom
merge

Conversation

@Byron

@Byron Sebastian Thiel (Byron) commented Nov 7, 2024 •
edited
Loading

Copy link
Copy Markdown
Member

Inspired by this git2 PR.

CC and credit to Caleb Owens (@Caleb-T-Owens) .

Follow-Up of #1658 .

Tasks

  • implementation and documentation
  • port tests
  • wire through to gix

Next PR

  • A way to know if a textual merge would have resulted in a conflict without auto-resolution.
  • 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.
  • A way write the conflict declaration into an index or adjust an optional index as well (which might be easier) so we get all the stages right.

Possible Tasks

  • Repository::merge_commits()
  • A trivial gix merge commit
  • 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

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.

@Byron
Sebastian Thiel (Byron) marked this pull request as ready for review November 7, 2024 19:46
@Byron
Sebastian Thiel (Byron) merged commit cf0c7ee into main Nov 7, 2024
This was referenced Nov 8, 2024
Merged
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@Byron