Re: [BUG] Highly inconsistent diff UI

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 24, 2013, 18:11 UTC
Message-ID: <7v38ufer2x.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0mVDT5ESnVJAWQ83gQnmxmGDoM_Y0nE4FGybcjcenA_KA@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> What are your thoughts on inventing a new syntax A~B = $(git
> merge-base A B) B which can be used by both range commands like log
> and non-range commands like diff ?  (In other words, why shouldn't log
> be able to do this?).

The idea for a new syntax to denote a merge base may be an interesting one.

"log" is inherently about ranges, so you do not need a new operator to denote a merge base. Between "log A..B" and "log A...B" with or without --left-right, --left-only and --right-only, you should be able to ask questions about histories leading to commit A and B without having to worry about a single "merge base" between A and B, no? So I do not think "A~B" would help "log".

Because "diff" is inherently about endpoints, you DO have to have a single "merge base" that gives you a point to compare something else against.

The reason why "diff A...B" was invented was primarily because we wanted to avoid having to say A twice on the command line, be it "diff $(git merge-base A B) B" or "diff A~B B". In other words, "A~B" will not help "diff" at all, either [*1*].

There isn't always a single merge base between an arbitrary pair of commits (there may be 0, or 2 or more). When used in the context of "diff A...B", we know that the user is more interested in using one merge base (among possibly many) to get some diff, than seeing the command fail [*2*]. Taking that as a context cue, "diff A...B" can (and did) choose to use one picked at random, even though the design is fully aware that the chosen one may not be the best one.

A generic "A~B" syntax implemented at the revision parser level may not have that luxury of assuming that it is fine to pick any, and may have to fail when there is not a unique merge-base.

[Footnote]

*1* That does not mean nobody needs that syntax.  It just means that
    it is still a solution looking for a problem.

*2* Otherwise the user can more carefully script what he wants to do
    using the merge-base command himself, choosing to do different
    things when there are 0, or 2 or more merge bases.