object-name: accept @{p} as short for @{push} - #2431

On Wed, Sep 30, 2026 at 4:06 PM Harald Nordgren via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Typing "git log @{p}.." fails with "unknown revision", even though
> "@{u}" works as the short form of "@{upstream}". Users who reach for
> the one letter spelling of the push destination by analogy get an
> error.
>
> Accept "@{p}" wherever "@{push}" is accepted, in any case, just like
> "@{u}".

I've oft wanted this. Though, I don't have a `p = push` (or `p =
pull`) alias set, because it could be short for either!

There's no "@{pull}", though, so that reasoning doesn't apply here.

I have to wonder if there's an older discussion around these notations
that explains why one got shorthand and the other didn't?

-- 
D. Ben Knoble

"D. Ben Knoble" <ben.knoble@gmail.com> writes:

> On Wed, Sep 30, 2026 at 4:06 PM Harald Nordgren via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
>>
>> From: Harald Nordgren <haraldnordgren@gmail.com>
>>
>> Typing "git log @{p}.." fails with "unknown revision", even though
>> "@{u}" works as the short form of "@{upstream}". Users who reach for
>> the one letter spelling of the push destination by analogy get an
>> error.
>>
>> Accept "@{p}" wherever "@{push}" is accepted, in any case, just like
>> "@{u}".
>
> I've oft wanted this. Though, I don't have a `p = push` (or `p =
> pull`) alias set, because it could be short for either!
>
> There's no "@{pull}", though, so that reasoning doesn't apply here.

Interesting thing to point out.  Letting @{push} squat on @{p} would
prevent us from adding @{pull} and anything that begins with 'p' in
the future (like 'previous', perhaps?).

> I have to wonder if there's an older discussion around these notations
> that explains why one got shorthand and the other didn't?

But we have lived with only two at_marks in the object name syntax,
for upstream and for push, and nothing else for quite some time.
So perhaps it is OK to assume that we do not have to worry about any
new ones in the future?

Digging the history, @{upstream} came in 2010 and @{push} came in
2015.

@{u} existed since the inception of @{upstream}, as we can see in
https://lore.kernel.org/git/20150331173740.GE18912@peff.net/ which
is the first iteration of the patch set that added @{push}.  It is
unclear what was said during the review of v2 [*] but in the review
of v3 https://lore.kernel.org/git/20150521045233.GA26507@peff.net/,
nobody questioned the asymmetry between @{upstream} having a
short-and-sweet @{u} while @{push} lacked the corresponding @{p}.

I do not know if that was because "push" was so short and easy to
type anyway?


[Footnote]

 * https://public-inbox.org/git/?q=gmane:268185 would have given us
   a good way to find what thread Peff was referring to in the cover
   letter of v3 iteration:

   https://lore.kernel.org/git/20150521044429.GA5857@peff.net/

   Unfortunately, we are getting 502 back X-<.

On Wed, Sep 30, 2026 at 03:07:44PM -0700, Junio C Hamano wrote:

> @{u} existed since the inception of @{upstream}, as we can see in
> https://lore.kernel.org/git/20150331173740.GE18912@peff.net/ which
> is the first iteration of the patch set that added @{push}.  It is
> unclear what was said during the review of v2 [*] but in the review
> of v3 https://lore.kernel.org/git/20150521045233.GA26507@peff.net/,
> nobody questioned the asymmetry between @{upstream} having a
> short-and-sweet @{u} while @{push} lacked the corresponding @{p}.

I think you have to go back further. Another contributor proposed
@{publish} with somewhat different semantics, and I requested that it
not use @{p} to avoid confusion between the two. There was also some
discussion of @{pull} (I think as an alias to @{upstream}) at the time,
which would further increase the confusion.

See this what's cooking and the actual patch threads around that time:

  https://lore.kernel.org/git/xmqqoazpt45p.fsf@gitster.dls.corp.google.com/

I don't remember what ultimately happened with the @{publish} series,
but given the time-frame and the contributor, I can make some guesses.

I don't think either of those name conflicts are under current
discussion, so I don't have any particular objection. Just noting the
history.

>  * https://public-inbox.org/git/?q=gmane:268185 would have given us
>    a good way to find what thread Peff was referring to in the cover
>    letter of v3 iteration:
> 
>    https://lore.kernel.org/git/20150521044429.GA5857@peff.net/
> 
>    Unfortunately, we are getting 502 back X-<.

I have a local archive, but the v2 thread is not enlightening. :)

-Peff

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Typing "git log @{p}.." fails with "unknown revision", even though
> "@{u}" works as the short form of "@{upstream}". Users who reach for
> the one letter spelling of the push destination by analogy get an
> error.

That's a weak justification.  The same argument may lead to a
different conclusion, i.e., we should remove @{u}, for example ;-)

As I wrote in my response to Ben Knoble, I dug the mailing list
history, and I think it is a good thing to record in the log message
of this change what we can learn from the history.  Things that you
should describe include 

 - @{upstream} had @{u} from the beginning
 - @{push} did not
 - the reason we do not have corresponding @{p} is not because
   somebody gave a concrete reason why we shouldn't while the
   feature was being added.

The last one is, as Ben brought up, a very good thing to mention, as
we can justify this change with "just for symmetry, add missing @{p}".

Queued.

Junio C Hamano <gitster@pobox.com> writes:

> [Footnote]
>
>  * https://public-inbox.org/git/?q=gmane:268185 would have given us
>    a good way to find what thread Peff was referring to in the cover
>    letter of v3 iteration:
>
>    https://lore.kernel.org/git/20150521044429.GA5857@peff.net/
>
>    Unfortunately, we are getting 502 back X-<.

Well, I remembered that gmane still offers nntp clients ;-)

We can visit nntp://news.gmane.io/gmane.comp.version-control.git/
and ask for article #268185 to learn that the thread begins with
the message <20150501224414.GA25551@peff.net>.

That's 12-patch series of v2 that can be seen at lore:

https://lore.kernel.org/git/20150501224414.GA25551@peff.net/

And then it also links back to a different thread

<1389126588-3663-1-git-send-email-artagnon@gmail.com>

that started <branch>@{publish} notation.  In one of the messages in
the discussion thread, I see I was asking

    If @{u} can already be used for upstream, why not allow @{p} but
    require two letters @{pu}?  Just being curious---I am not
    advocating strongly for a shorter short-hand.

The thread also has a fairly well written summary of what symmetric
and triangular workflows are, and how Git 2.0 would give users
choice to select among three simplest models.  The thread was
apparently from pre Git 2.0 days.

> > From: Harald Nordgren <haraldnordgren@gmail.com>
> >
> > Typing "git log @{p}.." fails with "unknown revision", even though
> > "@{u}" works as the short form of "@{upstream}". Users who reach for
> > the one letter spelling of the push destination by analogy get an
> > error.
>
> That's a weak justification.  The same argument may lead to a
> different conclusion, i.e., we should remove @{u}, for example ;-)
>
> As I wrote in my response to Ben Knoble, I dug the mailing list
> history, and I think it is a good thing to record in the log message
> of this change what we can learn from the history.  Things that you
> should describe include
>
>  - @{upstream} had @{u} from the beginning
>  - @{push} did not
>  - the reason we do not have corresponding @{p} is not because
>    somebody gave a concrete reason why we shouldn't while the
>    feature was being added.
>
> The last one is, as Ben brought up, a very good thing to mention, as
> we can justify this change with "just for symmetry, add missing @{p}".

Thanks, I'll take a look!


Harald

> Le 2 oct. 2026 à 03:50, Harald Nordgren via GitGitGadget <gitgitgadget@gmail.com> a écrit :
> 
> +test_expect_success '@{p} is short for @{push}' '
> +    test_config push.default current &&
> +    test_config branch.topic.pushremote other &&
> +    resolve topic@{p} refs/remotes/other/topic &&
> +    resolve topic@{P} refs/remotes/other/topic
> +'
> +

I don’t recall offhand if @{U} case-variant is supported, but I wonder
if we might not want to preserve as many single-character shorthands
as we can, since there are a limited number that are reasonable to
type.

If upstream already supports different cases, though, symmetry is probably best. 

> > +test_expect_success '@{p} is short for @{push}' '
> > +    test_config push.default current &&
> > +    test_config branch.topic.pushremote other &&
> > +    resolve topic@{p} refs/remotes/other/topic &&
> > +    resolve topic@{P} refs/remotes/other/topic
> > +'
> > +
>
> I don’t recall offhand if @{U} case-variant is supported, but I wonder
> if we might not want to preserve as many single-character shorthands
> as we can, since there are a limited number that are reasonable to
> type.
>
> If upstream already supports different cases, though, symmetry is probably best.

It surprised me too, but '@{U}' is actually supported already.


Harald

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> "git log @{p}" fails with "unknown revision", even though "@{u}"
> works for "@{upstream}".
>
> The "@{upstream}" notation came with its "@{u}" short form from the
> very beginning in 28fb84382b (Introduce <branch>@{upstream} notation,
> 2009-09-10). When "@{push}" was added in adfe5d0434 (sha1_name:
> implement @{push} shorthand, 2015-05-21), "@{p}" was held back to
> avoid confusion with a proposed "@{publish}" and talk of an "@{pull}".
> Neither of those was ever added.
>
> Add the missing "@{p}" for symmetry with "@{u}".
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---

Very well written.  Thanks.  Let me mark it for 'next'.