Re: commit-graph: change in "best" merge-base when ambiguous
- From
Jeff King <peff@peff.net>
- Date
- May 21, 2018, 21:54 UTC
- Message-ID
- <20180521215443.GC16623@sigill.intra.peff.net>
- In-Reply-To
- <e78a115a-a5ea-3c0a-5437-51ba0bcc56e1@gmail.com>
On Mon, May 21, 2018 at 02:10:54PM -0400, Derrick Stolee wrote:
Show 24 quoted lines
> In the Discussion section of the `git merge-base` docs [1], we have the > following: > > When the history involves criss-cross merges, there can be more than one > best common ancestor for two commits. For example, with this topology: > > ---1---o---A > \ / > X > / \ > ---2---o---o---B > > both 1 and 2 are merge-bases of A and B. Neither one is better than the > other (both are best merge bases). When the --all option is not given, > it is unspecified which best one is output. > > This means our official documentation mentions that we do not have a > concrete way to differentiate between these choices. This makes me think > that this change in behavior is not a bug, but it _is_ a change in behavior. > It's worth mentioning, but I don't think there is any value in making sure > `git merge-base` returns the same output. > > Does anyone disagree? Is this something we should solidify so we always have > a "definitive" merge-base?
Heh, I should have read your whole original message before responding, not just the part that Elijah quoted.
Yes, I think this is clearly a case where all of the single merge-bases we could show are equally good. And I don't think we should promise to show a particular one, but I _do_ think it's friendly for us to have deterministic tie-breakers (we certainly don't now).
-Peff