From: John Keeping Date: Sat, 07 Nov 2015 16:01:20 GMT Subject: Re: Git potential bug with fork-point Message-ID: <20151107160120.GG19802@serenity.lan> In-Reply-To: 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 [] Find the point at which a branch (or any history that leads to ) forked from another branch (or any reference) . This does not just look for the common ancestor of the two commits, but also takes into account the reflog of to see if the history leading to forked from an earlier incarnation of the branch (see discussion on this mode below). Clearly the order of the arguments matters because the reflog is only inspected for the `` 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 ` mode, which should give consistent results regardless of the order of the commits.