This fixes #1679

I just added a test case that is failing without my my change.

seems reasonable 👍

This is closer to git-core so it's good, but using the commit date assumes a world where distributed clocks work, which is often the case with git as it's used by humans, but there are commits out there with very wrong clocks (some on GitHub are beyond 2038).

Eventually we'll want to fix this to actually look at the graph and decide which of the merge bases isn't an ancestor, but this is good as a fix.

@carlosmn The way that merge bases are calculated is already correct, and follows the git-core implementation (at least that's what I understood from comparing the two implementations). So commits that aren't ancestors of both branches are already ignored.

The issue here is/was that we have 2 "best" merge bases, which is correct, and where you could use any of them to do diffs/merges. git-core just sorts the bases they return from youngest to oldest, and when you don't pass the --all flag, you get only the youngest. The libgit2 git_merge__bases_many implementation sorted the merge bases in the other direction, and would thus git_merge_base only returned the oldest merge base. If you then tried to emulate the git diff A...B syntax, you got different diffs.

The "best" merge base is defined as the one that's not an ancestor to any other, which means that we can't have two best merge bases unless neither is an ancestor which I'm fairly confident can't happen.

Anyway, we agree that those two merges from --all is what both implementations calculate correctly and we need to look at which one we should return when asked for a single one.

This is where the definition for "best" from the manpage comes into play. We chose the one that's not an ancestor of the other one. In all sane cases it is going to be the one with the newest timestamp. However, I can create a merge base today with a date of one year from now. Next week you create a new merge base with a correct timestamp and run this. The older (in real terms) commit would be returned. Conversely I could create a new one which is older than the existing ones.

Lange Rede kurzer Sinn, what I'm trying to say is that these decisions should happen by looking at the graph as we can't always trust timestamps and this is what the merge-base manpage says it does.

@carlosmn (don't want to argue with you but) git-core also sorts by date: https://github.com/git/git/blob/master/commit.c#L832

That's for showing all, not determining which is the best for single-output mode. I'll get home shortly and I'll investigate further

@carlosmn https://github.com/git/git/blob/master/builtin/merge-base.c#L6 just takes the first result when all is not given, and outputs all when all is given.

Also, even the man page specifies that there can be multiple "best" merge bases, in case there is a criss-cross merge.

Oh, and that example that I have in my test-case atually looks like a criss-cross merge I think.

Yes, I was confusing which stage we were at. The list is indeed of merge bases so we have already taken the history into account. If we do actually have multiple merge bases, then we have a criss-cross merge and it's undefined what we show when the user doesn't ask for all of them. So in the end this isn't any more correct, just happens to have the same implementation detail as git-core.