Branches and Merge capabilities

[nallapan]

Need support for branching and three-way merge capabilities in go-git which bring it closer to libgit2 in comparison. Many use cases for embedding git need these features.

[disastrous-charly]

It isn't possible to merge 2 branches at the moment ?

[pjebs]

https://github.com/src-d/go-git/blob/master/COMPATIBILITY.md

Based on this, you cant.

Just a question, how hard is it to implement merging and cherry-picking?

[zhaopengme]

commented 11 months ago It isn't possible to merge 2 branches at the moment ?

[vishjosh]

@mcuadros What kind of help do you need to make sure this feature is implemented? Our company can sponsor it if needed. We just need to know what exactly needs to be done to implement this feature

[Gregory-Ledray]

I want to contribute to resolve this issue in a limited way, but I'm not sure about the scope. So far I've written a draft of recursive merge over on my branch at https://github.com/Gregory-Ledray/go-git

I'm more or less implementing a limited set of options of the recursive merge. It would have these features and caveats, from the docs:

• 2 branch merging only. So it'll err on >2 branches and there's no Octopus merge. This is a deviation from the git docs, but it's just because I haven't written an Octopus merge algorithm.
• Fast forward merge when possible (which is already implemented in go-git)
• Recursive merge, but I'll only support the 'ours' and 'theirs' strategies.
• Since the 'ours' and 'theirs' strategies don't generate merge conflicts (as far as I know), I won't dev anything related to editing the Filesystem and inserting merge conflict markers.
• Won't handle multiple common ancestors - instead, it throws an error. This isn't in-scope because I found some references to merging the common ancestors to create a 'virtual branch' as an ancestor. This is possible to write in go-git, and I'll try to write my code to support such a thing in the future (probably in the 2nd draft), but I don't want to implement a virtual branch right now and I couldn't find an easy way to create one.
• It throws an error if there are unstaged changes in the Worktree when you use recursive merge, which is NOT how git works (see question 2 below)
• Currently there are no special paths for binaries (see question 5 below)

I think this is a reasonably small change which is why I want to do this instead of fully implementing recursive merge with merge conflict markers. But I have some questions:

1. What is the accepted default commit signature in go-git? This is what I have right now as a default for a merge commit: o.CommitOptions = &CommitOptions{ All: true, Author: &object.Signature{ Name: "foo", Email: "[email protected]", When: time.Now(), }, }

2. Is it OK to not support having unstaged changes in the Worktree when using recursive merge when git does support that?

3. Would these changes be sufficient to close this Issue?

4. Can I update documentation in other files when I'm writing this? I've noticed a lot of internal functions have less documentation than I would like.

5. Does go-git have binary support?

6. Writing tests, etc. to get it to work should be easy (although FYI I have barely started them). But where the documentation should be done is less clear. I assume I should be writing a new example in _examples, but what other documentation needs to be done for an enhancement? Is there some process I need to go through to submit a design?

It looks like the Slack channel is defunct, so I assume this is the best way to contact the maintainers. @mcuadros @strib @orirawlings (sorry if you don't like @ 's).

[nathanhack]

Merging would be hugely useful - even if it's limited. I'm sure there are others that would like this feature besides myself. @Gregory-Ledray please consider putting in a PR for the work you've done.

[Gregory-Ledray]

Merging would be hugely useful - even if it's limited. I'm sure there are others that would like this feature besides myself. @Gregory-Ledray please consider putting in a PR for the work you've done.

I'm hesitant to submit a PR in part because one of the project's goals is to ensure parity with regular Git to prevent confusion, and the code I've written fails to do that because it's so limited. There's also the maintainability problem - I'm not associated with the maintainers and they would have to fully understand my code. I can't be certain this is OK with the maintainers until they answer my questions.

Until then I won't do any more dev on this since, frankly, finishing the PR and doing code review will be a pain in the butt for both me and the maintainers to do. The problem is that there are multiple ways you could try to implement merging in go-git right now and I doubt I picked the right one. I would also expect a PR to have quite a bit of back and forth about the approach before we even get to the specifics of syntax and tests, so it won't be as simple as most of the community PRs on this repo.