Re: merge-base not working as expected when base is ahead

From: Michael J Gruber <git@grubix.eu>
Date: Sep 14, 2017, 08:09 UTC
Message-ID: <68633b20-9e2b-ae23-2ede-8728283250f0@grubix.eu>
In-Reply-To: <e697e5f0da0845ee92ffdb88a4fa48d9@SFSWW2K12EX02.intern.fsw.at>

Ekelhart Jakob venit, vidit, dixit 13.09.2017 17:07:

Show 17 quoted lines

> Dear Git,
> 
> git merge-base --fork-point "master" not working if master is already newer then my current branch.
> Very oddly it seems to work whenever you had the expected commit checked out previously - what made it very tricky to detect this problem.
> 
> Example:
>  - Clone "https://github.com/jekelhart/GitInfoTry"
>  - Switch to branch "v1.0.0"
>  - git merge-base --fork-point "master"
>    - or: git merge-base --fork-point "origin/master" 
>  - expected result: fork point "fbb1db34c6317a6e8b319c1ec261e97ca1672c22"
>  - but result is empty
> 
> In the repo where we created this example tree in the first place the command returned the expected fork point. If you clone it new and fresh it does not return any result anymore.
> 
> Works, however, on branch "v2.0.0". Assumption: because "master" is older.(?)
> I think it works locally because the command uses the reflog in addition(!), however, it should work without the local reflog as well. (since the history was not modified in any way)

The documentation lies, unfortunately. It claims that in fork-mode, "git merge-base" "also" looks at the reflog. In fact, the code explicitely *discards* any merge bases that it finds but which are not in the reflog. (The merge base that you find for v2.0.0 is in the reflog because it's the checked out HEAD.)

Removing the corresponding check gives the merge base for v1.0.0 that you expect, and git still passes all tests. But I'll look at the history of these lines before I submit a patch.

Michael