[PATCH] object-name: accept @{p} as short for @{push}

[PATCH] object-name: accept @{p} as short for @{push}

[Harald Nordgren via GitGitGadget]

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}".

Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
    object-name: accept @{p} as short for @{push}
    
    @{u} works as the short form of @{upstream}, but @{p} fails with
    "unknown revision". This makes @{p} resolve to the same branch as
    @{push}, in any case, and documents it next to @{u}.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2431%2FHaraldNordgren%2Fpush-shorthand-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2431/HaraldNordgren/push-shorthand-v1
Pull-Request: https://github.com/git/git/pull/2431

 Documentation/revisions.adoc | 2 +-
 object-name.c                | 2 +-
 t/t1514-rev-parse-push.sh    | 7 +++++++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/Documentation/revisions.adoc b/Documentation/revisions.adoc
index 3fbfbd3d5f..68ce6f3dc2 100644
--- a/Documentation/revisions.adoc
+++ b/Documentation/revisions.adoc
@@ -122,7 +122,7 @@ some output processing may assume ref names in UTF-8.
   `branch.<name>.remote`). B@{u} refers to the remote-tracking branch for
   the branch X taken from remote R, typically found at `refs/remotes/R/X`.
 
-'[<branchname>]@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
+'[<branchname>]@\{push\}', e.g. 'master@\{push\}', '@\{p\}'::
   The suffix '@\{push}' reports the branch "where we would push to" if
   `git push` were run while `branchname` was checked out (or the current
   `HEAD` if no branchname is specified). Like for '@\{upstream\}', we report
diff --git a/object-name.c b/object-name.c
index 4eda8c8eac..6546685760 100644
--- a/object-name.c
+++ b/object-name.c
@@ -657,7 +657,7 @@ static inline int upstream_mark(const char *string, int len)
 
 static inline int push_mark(const char *string, int len)
 {
-	const char *suffix[] = { "@{push}" };
+	const char *suffix[] = { "@{push}", "@{p}" };
 	return at_mark(string, len, suffix, ARRAY_SIZE(suffix));
 }
 
diff --git a/t/t1514-rev-parse-push.sh b/t/t1514-rev-parse-push.sh
index d868a08110..5a4f16867a 100755
--- a/t/t1514-rev-parse-push.sh
+++ b/t/t1514-rev-parse-push.sh
@@ -60,6 +60,13 @@ test_expect_success '@{push} with pushremote defined' '
 	resolve topic@{push} refs/remotes/other/topic
 '
 
+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
+'
+
 test_expect_success '@{push} with push refspecs' '
 	test_config push.default nothing &&
 	test_config remote.origin.push refs/heads/*:refs/heads/magic/* &&

base-commit: a018953688f1b10bddf91bff8747068f5f4746a4
-- 
gitgitgadget

Re: [PATCH] object-name: accept @{p} as short for @{push}

[D. Ben Knoble]

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

Re: [PATCH] object-name: accept @{p} as short for @{push}

[Junio C Hamano]

"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-<.

Re: [PATCH] object-name: accept @{p} as short for @{push}

[Jeff King]

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

Re: [PATCH] object-name: accept @{p} as short for @{push}

[Junio C Hamano]

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.

Re: [PATCH] object-name: accept @{p} as short for @{push}

[Junio C Hamano]

"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.

Re: [PATCH] object-name: accept @{p} as short for @{push}

[Harald Nordgren]

> > 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

[PATCH v2] object-name: accept @{p} as short for @{push}

[Harald Nordgren via GitGitGadget]

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>
---
    object-name: accept @{p} as short for @{push}
    
    @{u} works as the short form of @{upstream}, but @{p} fails with
    "unknown revision". This makes @{p} resolve to the same branch as
    @{push}, in any case, and documents it next to @{u}.
    
    Changes in v2:
    
     * Commit message explains history.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2431%2FHaraldNordgren%2Fpush-shorthand-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2431/HaraldNordgren/push-shorthand-v2
Pull-Request: https://github.com/git/git/pull/2431

Range-diff vs v1:

 1:  f772f79954 ! 1:  1097f119a3 object-name: accept @{p} as short for @{push}
     @@ Metadata
       ## Commit message ##
          object-name: accept @{p} as short for @{push}
      
     -    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.
     +    "git log @{p}" fails with "unknown revision", even though "@{u}"
     +    works for "@{upstream}".
      
     -    Accept "@{p}" wherever "@{push}" is accepted, in any case, just like
     -    "@{u}".
     +    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>
      


 Documentation/revisions.adoc | 2 +-
 object-name.c                | 2 +-
 t/t1514-rev-parse-push.sh    | 7 +++++++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/Documentation/revisions.adoc b/Documentation/revisions.adoc
index 3fbfbd3d5f..68ce6f3dc2 100644
--- a/Documentation/revisions.adoc
+++ b/Documentation/revisions.adoc
@@ -122,7 +122,7 @@ some output processing may assume ref names in UTF-8.
   `branch.<name>.remote`). B@{u} refers to the remote-tracking branch for
   the branch X taken from remote R, typically found at `refs/remotes/R/X`.
 
-'[<branchname>]@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
+'[<branchname>]@\{push\}', e.g. 'master@\{push\}', '@\{p\}'::
   The suffix '@\{push}' reports the branch "where we would push to" if
   `git push` were run while `branchname` was checked out (or the current
   `HEAD` if no branchname is specified). Like for '@\{upstream\}', we report
diff --git a/object-name.c b/object-name.c
index 4eda8c8eac..6546685760 100644
--- a/object-name.c
+++ b/object-name.c
@@ -657,7 +657,7 @@ static inline int upstream_mark(const char *string, int len)
 
 static inline int push_mark(const char *string, int len)
 {
-	const char *suffix[] = { "@{push}" };
+	const char *suffix[] = { "@{push}", "@{p}" };
 	return at_mark(string, len, suffix, ARRAY_SIZE(suffix));
 }
 
diff --git a/t/t1514-rev-parse-push.sh b/t/t1514-rev-parse-push.sh
index d868a08110..5a4f16867a 100755
--- a/t/t1514-rev-parse-push.sh
+++ b/t/t1514-rev-parse-push.sh
@@ -60,6 +60,13 @@ test_expect_success '@{push} with pushremote defined' '
 	resolve topic@{push} refs/remotes/other/topic
 '
 
+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
+'
+
 test_expect_success '@{push} with push refspecs' '
 	test_config push.default nothing &&
 	test_config remote.origin.push refs/heads/*:refs/heads/magic/* &&

base-commit: a018953688f1b10bddf91bff8747068f5f4746a4
-- 
gitgitgadget

Re: [PATCH v2] object-name: accept @{p} as short for @{push}

[Ben Knoble]

> 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. 

Re: [PATCH v2] object-name: accept @{p} as short for @{push}

[Harald Nordgren]

> > +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

Re: [PATCH v2] object-name: accept @{p} as short for @{push}

[Junio C Hamano]

"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'.