Git potential bug with fork-point

Git potential bug with fork-point

[Stenberg Jim (2)]

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

Re: Git potential bug with fork-point

[John Keeping]

On Mon, Nov 02, 2015 at 06:27:52AM +0000, Stenberg Jim (2) wrote:
> 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.