Re: Our merge bases sometimes suck

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 17, 2014, 15:08 UTC
Message-ID: <xmqq8uovo9pa.fsf@gitster.dls.corp.google.com>
In-Reply-To: <539A25BF.4060501@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 22 quoted lines

> The "best" merge base
> =====================
>
> But not all merge bases are created equal.  It is possible to define a
> "best" merge base that has some nice properties.
>
> Let's focus on the command
>
>     git diff $master...$branch
>
> which is equivalent to
>
>     git diff $(git merge-base $master $branch)..$branch
> ...
> I propose that the best merge base is the merge base "candidate" that
> minimizes the number of non-merge commits that are in
>
>     git rev-list --no-merges $candidate..$branch
>
> but are already in master:
>
>     git rev-list --no-merges $master

I welcome this line of thought very much.

There is one niggle I find somewhat curious but am either too lazy or too stupid to think it through myself ;-)

The "merge-base" is a symmetric operation, because the three-way merge, which is the primary customer of its result, fundamentally is. From your description, it sounds like the "best" merge base however may not be symmetric at all. The merge-base between A and B that makes "git diff A...B" the easiest to read by minimizing the distance between it and B may be different from the merge-base between A and B that makes the other diff "git diff B...A" the easiest to read.

Or it may not be assymmetric---that is why I said I didn't think it through. I am not saying that it is bad if the "best" merge-base is an asymmetric concept; I am curious if it is asymmetric, and if so if that is fundamental.