Git potential bug with fork-point

Stenberg Jim (2)· Nov 2, 2015, 06:27 UTC · lore

Hello, my name is Jim Stenberg and I'm a developer, albeit not that experienced with Git. Please note that I'm not a native English speaker. If there is anything unclear or lacking, feel free to ask me on this email address.

My problem: "Git merge-base --fork-point" acts unexpected when I refer to remote branches (typically "origin/".) With unexpected I mean that if I swap the position of the two references that the function takes as argument I get different results. I highly suspect that this isn't a feature but a bug, or maybe I'm using the function in a way it wasn't intended to be used. I don't need you to fix it (swapping the arguments solves it), I just want you to be aware of it.

History & procedure: When I was working on my automatic build script I came across the oddity that "Git merge-base --fork-point" behaved differently depending on the order in which the two references are passed. I tried to strip the problem down to the smallest example I could. Such example uses: . A local folder as repository, initialized by "git init --bare" . A local clone, acquired by "git clone ../my/path/to/repo repoName" . Populated with a few files and commits. I first detected the problem on git version 1.9.5.msysgit.0 but could confirm the same behavior on git version 2.6.2.windows.1. I've pasted a log in text form below, the message did not allow for appended images. The log should be sufficient to reproduce the problem. Please observer the additional new-lines in the log and that no errors or fault messages are presented.

System configuration: OS Name: Microsoft Windows 7 Enterprise OS Version: 6.1.7601 Service Pack 1 Build 7601 OS Manufacturer: Microsoft Corporation OS Configuration: Member Workstation OS Build Type: Multiprocessor Free System Type: x64-based PC Total Physical Memory: 3 977 MB Available Physical Memory: 841 MB

Log: C:\Test\Local\Main>git version git version 2.6.2.windows.1

C:\Test\Local\Main>git plot
* a17df67 (HEAD -> release/15.F, origin/release/15.F) try try again
* 2af2f42 Other solution to fork-point problem, change position of arguments
* 8bb3a5e more bugfixing, in release branch is now also checked against server
* 9db0a3c bugfix, fork-point do not work with origin/* => use only merge-base
* 6489785 Check on origin/release/* instead of release/*
* 12cd1af X -> T
* 2dde79c P -> X && 15.D -> 15.F
* ffefe54 15.F -> 15.D
* 634e81d T->P
* f4003e5 Overhauled the ECU split solution
* 0e1bc85 reverting even more
* c0e1391 incorrectly changed to X release
* faaa7e8 changed to P release
* 51d5588 Finishing touch, + fault codes
* c03f0b4 canges, ready for release?
* 09a7ed6 (origin/master, master) minor bug fixing
* 4bdb033 (tag: 15.D) Added required files

C:\Test\Local\Main>git merge-base --fork-point release/15.F master 09a7ed6294ae18fb6087ca1ee020d544f4efe28d

C:\Test\Local\Main>git merge-base --fork-point master release/15.F 09a7ed6294ae18fb6087ca1ee020d544f4efe28d

C:\Test\Local\Main>git merge-base --fork-point master origin/release/15.F 09a7ed6294ae18fb6087ca1ee020d544f4efe28d

C:\Test\Local\Main>git merge-base --fork-point origin/master origin/release/15.F

09a7ed6294ae18fb6087ca1ee020d544f4efe28d

C:\Test\Local\Main>git merge-base --fork-point origin/release/15.F origin/master

C:\Test\Local\Main>git merge-base --fork-point origin/release/15.F master

C:\Test\Local\Main>

Literature index: When reading https://git-scm.com/docs/git-merge-base I didn't found any information about this particular case. I didn't find any list of known bugs, hence I can't confirm if it's reported or not.

_________________________________________________ Med Vänliga Hälsningar / Best Regards Jim Stenberg M.Sc. ECU node owner

Volvo Bus Corporation
Dept CD74230, ARAK3
SE-405 08 Göteborg, Sweden
Phone: +46 31 32 25173
Email: jim.stenberg.2@volvo.com

John Keeping· Nov 7, 2015, 16:01 UTC · re: Stenberg Jim (2) · lore

Re: Git potential bug with fork-point

On Mon, Nov 02, 2015 at 06:27:52AM +0000, Stenberg Jim (2) wrote:

Show 14 quoted lines

> My problem:
> "Git merge-base --fork-point" acts unexpected when I refer to remote
> branches (typically "origin/".) With unexpected I mean that if I swap
> the position of the two references that the function takes as argument
> I get different results.  I highly suspect that this isn't a feature
> but a bug, or maybe I'm using the function in a way it wasn't intended
> to be used.
> I don't need you to fix it (swapping the arguments solves it), I just
> want you to be aware of it.
> 
> History & procedure:
> When  I was working on my automatic build script I came across the
> oddity that "Git merge-base --fork-point" behaved differently
> depending on the order in which the two references are passed.

I think this is expected.  The documentation for `--fork-point` says:

	git merge-base --fork-point <ref> [<commit>]

	Find the point at which a branch (or any history that leads to
	<commit>) forked from another branch (or any reference) <ref>.
	This does not just look for the common ancestor of the two
	commits, but also takes into account the reflog of <ref> to see
	if the history leading to <commit> forked from an earlier
	incarnation of the branch <ref> (see discussion on this mode
	below).

Clearly the order of the arguments matters because the reflog is only inspected for the `<ref>` argument. Since the reflog is involved this also means that the results are likely to be different between separate copies of the same repository.

I suspect you do not want to be using `--fork-point` in your build script; it is intended to help `git rebase` recover from history being rewritten and if you do not need that behaviour you are probably better off using the normal `git merge-base <commit> <commit>` mode, which should give consistent results regardless of the order of the commits.