On Thu, Feb 17 2022, Junio C Hamano wrote:
> Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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? :)
