Re: [PATCH] branch: delete now accepts '-' as branch name

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Thu, Feb 17 2022, Junio C Hamano wrote:

> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>> Perhaps. Perhaps not. I may be misreading Junio's responses in this
>> thread, but it didn't seem like he was necessarily opposed to the
>> change.
>
> I do not care too much about this issue to expend my political
> capital on enforcing my preference ;-)
>
> FWIW, my preference in an ideal world would be to limit "-" as a
> short-hand to go back to previous (i.e. "checkout -"), which can be
> justified with similarity to "cd -", but do not add any more use.
> If we could, I would even deprecate "merge -", "rebase -", etc. that
> can not be justified with similarity to "cd -", but I think we came
> too far for that.
>
> "-" cannot be used as a universal "the branch we last 'git checkout'
> out of" notation because some commands and people expect "-" to be
> something else, like "read from the standard input".  The only two
> reasons this pops up from time to time is because "checkout -"
> exists and because "@{-N}" notation, which is accepted everywhere
> uniformly and does not have problems "-" has, is not very well
> known.
>
>> A documentation update as in [1] would be a good idea, though,
>> if resubmitted.
>
> Yeah, [1] talked about both "@{-1}" and "-", but limiting it to the
> former may make sense.  It feels a bit odd that we single out "git
> branch" and describe "@{-1}" there, when the notation is universally
> available, though.
>
>     $ git grep -l '@{-' -- Documentation/ :\!Documentation/\*/\*
>
> shows hits only in check-ref-format, checkout, switch, and worktree,
> but the mention in "revisions.txt" is included in all commands in
> the "log" family of commands.  If we add one to "branch", we should
> at least teach "@{-1}" to the documentation of merge, rebase, and
> revert.  The hits we see here
>
>     $ git grep -l -B1 '"@{-' \*.c
>     builtin/checkout.c
>     builtin/merge.c
>     builtin/rebase.c
>     builtin/revert.c
>     builtin/worktree.c
>
> all are about replacing "-" the user typed with "@{-1}".
>
> Continuing the "thinking aloud" a bit, I _think_ this tells us these
> things:
>
>  * @{-1} has way too many letters to type to be liked by users, who
>    won't learn or remember what they do not appreciate (and do not
>    blame them---it is a bad notation).
>
>  * @{-<n>} may have been a generalized way that satisfied geeky mind
>    while being implemented, but the users only need the "last one"
>    and no such generalization.
>
> If it is too late for a more easy-to-type-and-pleasant-to-eyes
> notation, perhaps "@-", that does not have downsides of "-" or
> "@{-1}", I have to wonder.

I too find the syntax really annoying to type.

I wonder if we couldn't say that:

 * @[-]N is the same as @{[-]N}. I.e. @1 is the same as @{1} and @{-1}
   is the same as @-1

 * Optionally (and this is a bit nasty) say that @{-} is a synonym for
   @{-1}, and therefore @- is the same as @-1 is the same as @{-1}.

   Nasty because the logical conclusion would be that @ is the same as
   @1, but it's HEAD, but this would allow us to have a shorter "@-" for
   "delete last", as opposed to "@-1". Also @{-0} (which would presumably
   be a synonym for "HEAD", or "@" errors out currently, and would continue
   to do so).

 * Declare that any other single-letter special @{...} syntax is the
   same as @...; In particular that @u would be @{u} which is short for
   @{upstream}.

 * Live more dangerously and allow @push @upstream etc.? One the one
   hand it feels a bit usurp-y to close the door on such a syntax having
   a similar meaning as regex flags where /ix is /i and /x, but on the
   other hand I don't really see us wanting @pu for "@push" and
   "@upstream" at the same time (makes no sense...).

I haven't hacked it up (and won't any time soon), Erlend: are you
interested? :)