Open Caleb-T-Owens opened 2 days ago
I've just read the git documentation... https://git-scm.com/docs/git-merge-base#_discussion (I probably should have done that first 🤦). It seems like this really is indeed the intended behavior.
Sounds like what I really want is --octopus
or merge_base_octopus
.
I might have a go at writing a small note about this in the documentation tomorrow.
I'm not sure if this is a bug report per-se, given that there have been test cases in libgit2 for the last 12 years which confirm this behavior.
I've been making use of
merge_base_many
in GitButler to find the common merge base between N commits. However, while writing tests cases I found some unexpected behavior, and the source seems to be the fact thatmerge_base_many
returns different results depending on the order of the arguments! My understanding was that it should always return the commit that is a shared base among all of them.Here is my rust code in case I'm making some daft mistake:
But, I've also laid out the scenario a little nicer:
There however seems to be test cases that indicate that there might be intended behavior going on here? https://github.com/libgit2/libgit2/blob/main/tests/libgit2/revwalk/mergebase.c#L243-L245 (PR: https://github.com/libgit2/libgit2/pull/753)
If this is intended, it would be great if it could be documented, because this was rather unexpected to me.
I'll talk to Scott about this tomorrow as well in case my understanding is flawed, and come back to update here and the docs if it turns out I'm expecting the wrong behavior, so others don't get confused buy the behavior.
Version of libgit2 (release number or SHA1)
git2-rs 0.19 / 1.8.1 (but tests in the repo HEAD indicate the "issue" is still in place, and has been around for a while)
Thanks for the great work on libgit2 btw!!