From: Linus Torvalds Date: Wed, 09 Nov 2005 21:58:33 GMT Subject: Re: Comments on recursive merge.. Message-ID: In-Reply-To: <7virv1efzv.fsf@assigned-by-dhcp.cox.net> On Wed, 9 Nov 2005, Junio C Hamano wrote: > > The current show-branch code does the same as merge-base in the > pathological example depicted in merge-base.c, but they seem to > do different things to this picture (commit grows from bottom to > top, time flows alphabetically; find base between G and H). > > H > / \ > G A \ > |\ / \ > | B \ > | \ \ > \ C F > \ \ / > \ D / > \ | / > \| / > E > > "git-merge-base --all" says the merge bases are B and E, while > "show-branch --merge-base" mentions only B. In this case the > latter is probably the better answer. I don't agree. Sure, B _may_ be the right answer for a particular merge strategt, but there's no way of knowing. Maybe all the big changes came in through F, and H is the merge that sorted that out, and E actually ends up being the better base. So I think from a correctness standpoint, the only thing that matters is "git-merge-base --all", and anything that doesn't know to return both E and B looks potentially buggy. > Actually git-merge-base without --all only mentions E. Well, we should really consider anything that doesn't take them all into account to be a bug waiting to happen (or rather, a merge waiting for a disaster), but E is the right one, since it's the more recent one). Now, this case obviously depends on history being almost maximally insane (ie pretty much _all_ the dates are wrong). So in practice we probably don't care. So maybe "git-show-branch --merge-base" ends up acceptable as a faster way to do the quick "let's see if we can find _some_ merge-base to do the in-index merge with", but personally I'd much rather always do a "git-merge-base --all", and only do the fast index merge if we only have one potential parent. That way there would never any question about what the "quick merge" does. Linus