Re: Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?

From: Martin von Zweigbergk <martinvonz@gmail.com>
Date: Dec 21, 2012, 21:31 UTC
Message-ID: <CANiSa6hcDHTpZnAXR3zxdv-H4r-yRjuSx_kgE5V1rSFk_pNhOA@mail.gmail.com>
In-Reply-To: <50D4BBDC.6030700@alum.mit.edu>

On Fri, Dec 21, 2012 at 11:43 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:

Show 7 quoted lines

> On 12/21/2012 06:12 PM, Junio C Hamano wrote:
>> "diff" is always about two endpoints, not the path that connects
>> these two endpoints (aka "range"), and when you want to "diff"
>> between two commits, you say "diff A B".  "A..B" happens to be
>> accepted as such only by accident (e.g. the old command line parser
>> did not have a reliable way to tell "^A B" and "A..B" apart), not by
>> design.

Off topic: I also find it hard to wrap my head around what diffing against a negative revision would mean. Looking at the result of running it, it seems to be the same as diffing against a positive one.

Show 9 quoted lines

>>
>>     side note: incidentally, now we have rev_cmdline_info support,
>>     we could start deprecating "diff A..B" syntax.
>
> I often find myself using "git diff A..B" syntax when using the command
> line history because the previous command used "A..B"; e.g.,
>
>     git log A..B
>     git diff A..B

The problem with this, to me, if it wasn't clear, is that "git log A..B" shows you is new _since B branched off from A_, while "git diff A..B" shows you what has changed _between A and B_.

Show 13 quoted lines

>> Actually, in many places where the command line parser knows it
>> wants a single point, and never a range, we should be able to apply
>> the "A...B as a notation to specify a single point" rule.
>>
>> Of course you could come up with a symbol other than "..." for that
>> purpose, and migrate the current "git checkout A...B" special case
>> to use that other symbol, but that would be more work and also you
>> would need to retrain existing users.
>
> OTOH making A...B sometimes mean a range and sometimes a merge-base
> (depending on context) adds a confusing non-uniformity, and also has the
> disadvantage of making merge-base shorthand unavailable in contexts that
> allow a range.

And making it unavailable in contexts where the command was not specifically implemented to support it. I'm sure there are many scripts out there that use "git ... $(git merge-base A B) ..." that could be simplified if rev-parse could resolve a merge base.

> OTOOH git already has so many notations that can be used on the command
> line; inventing yet another one would make it that much more overwhelming.

Agreed.