Commits not counting correctly when base branch is already ahead

[jmajnek]

GitInfo uses the command "git merge-base" to detect fork points. However this seems to not work whenever the "base-branch" is already ahead. Consequently the commit count does not work correctly.

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.(?)

BR, Jakob

[matthiaslischka]

It seems to be a bug in Git itself. We issued this in the git mailing list and that is the response:

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.

I think this is a huge problem for gitinfo because it means that commit counting will not work on a repo without the reflog (e.g. build server) as soon as the branch where the fork was made from is ahead.
I don't know how soon this will be fixed in git.
I'm not sure what the best way to continue is. Even if this fix is released soon it would make gitinfo still only work correctly with the newest git version. Maybe the method of finding the fork point commit should be replaced in gitinfo with some alternative method? At least for the time being. :/

BR

[matthiaslischka]

Workaround: use tags instead of branch naming.
If you use tags you should not have any problems. Just be aware that if you have both, a branch with a matching name and a tag, the branch seems to win over the tag and you still have this problem.

Follow the Git bugfix discussion on the mailing list archive: https://public-inbox.org/git/68633b20-9e2b-ae23-2ede-8728283250f0@grubix.eu/T/

BR

[kzu]

If you decide to switch to tags, you can set GitIgnoreBranchVersion=true and therefore you should never hit this issue.

I'm not sure there's much else we can do. Although there are usually so many ways of doing the same thing in git that maybe there is an alternative way to lookup the fork point that is more reliable?

[kzu]

Closing for now, plz do reopen if there's a suggested tweak we could make to support this with a different git command.

Thanks!

[matthiaslischka]

Why would you close this issue? It should be treated as a known, active issue until fixed - at least until there is a git version available with which this works again. Better yet, until it is fixed backwards compatible in gitinfo.
However, on the bright sight, the fix in git seems to be already merged to the "proposed updates" branch of git: git/git@367a8bf

BR Matthias

[kzu]

Being an external dependency where there is nothing we can do about it, I fail to see how keeping it open helps ;)

In more advanced bug tracking systems, this would be a "RESOLVED / [UPSTREAM|EXTERNAL]"

[duffleit]

But it helps finding the issues and avoids creating a duplication. Let's introduce a "Git-Related-Issue" tag and keep it open.