From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 30 Mar 2015 19:46:56 GMT
Subject: Re: [PATCH/RFC 1/4] Add "-" as @{-1} support for the rev-parse command
Message-ID: <xmqqy4mew9n3.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1427737315-7229-2-git-send-email-kenny.lee28@gmail.com>

Kenny Lee Sin Cheong <kenny.lee28@gmail.com> writes:

> Allows the use of the "-" shorthand notation, including
> use with revision ranges. If we plan to allow "-" as a stand in every
> where a revision is allowed, then "-" would also need to be usable in
> plumbing commands, for writing tests, for example.
>
> Checks if the argument can be interpreted as a revision range first
> before checking for flags. This saves us from having to check that
> something that begins with "-" does not get checked as a possible flag.

Doesn't that mean -<something> that is a valid flag can no longer be
recognised as a flag if the same string can be an extended SHA-1
whose formulation starts from "the previous branch"?  It sounds like
a regression to me.

Hmmm.

After all, "we often call for the previous branch, so let's give a
short-and-sweet '-' as an even shorter short-hand than '@{-1}'" and
"allow '-' anywhere" are two quite different things.  We may do "git
checkout -" very often to go back to what we were working on, but I
do not think "git log -.." or "git log ..-" are something we want to
do very often.

I think what I am saying is that it may be perfectly fine if we said
"'-' can be used for '@{-1}' only by itself; no ranges, no
parent-traversals, no other uses", if it makes it less likely for
mistakes and confusions to happen.