Volume XXII, number 279Tuesday, October 6, 2026Latest message 33 minutes ago

The Git List

News and archive of git@vger.kernel.org, since April 2005

patchobject-name: accept @{p} as short for @{push}

11 messages between Sep 30, 2026 and Oct 2, 2026, from Harald Nordgren via GitGitGadget, D. Ben Knoble, Junio C Hamano, Jeff King, Harald Nordgren, Ben Knoble.

Plain Markdown or JSON for tools and agents. Diffs are folded; open one to read it.

Harald Nordgren via GitGitGadgetSep 30, 2026, 19:39 UTC on lore
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(-)
Show changes to 3 files +9 −2

Documentation/revisions.adoc, object-name.c, t/t1514-rev-parse-push.sh

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
D. Ben KnobleSep 30, 2026, 21:39 UTC in reply to Harald Nordgren via GitGitGadget on lore

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

On Wed, Sep 30, 2026 at 4:06 PM Harald Nordgren via GitGitGadget <gitgitgadget@gmail.com> wrote:

Show 10 quoted lines
>
> 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
Junio C HamanoSep 30, 2026, 22:07 UTC in reply to D. Ben Knoble on lore

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

"D. Ben Knoble" <ben.knoble@gmail.com> writes:
Show 17 quoted lines
> 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-<.
Jeff KingSep 30, 2026, 22:39 UTC in reply to Junio C Hamano on lore

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

On Wed, Sep 30, 2026 at 03:07:44PM -0700, Junio C Hamano wrote:
Show 7 quoted lines
> @{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.

Show 7 quoted lines
>  * 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
Junio C HamanoSep 30, 2026, 22:52 UTC in reply to Harald Nordgren via GitGitGadget on lore

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

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 6 quoted lines
> 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 HamanoOct 1, 2026, 03:29 UTC in reply to Junio C Hamano on lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 9 quoted lines
> [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.

Harald NordgrenOct 1, 2026, 07:05 UTC in reply to Junio C Hamano on lore

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

Show 23 quoted lines
> > 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
Harald Nordgren via GitGitGadgetOct 2, 2026, 07:49 UTC in reply to Harald Nordgren via GitGitGadget on lore

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

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(-)
Show changes to 3 files +9 −2

Documentation/revisions.adoc, object-name.c, t/t1514-rev-parse-push.sh

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
Ben KnobleOct 2, 2026, 12:08 UTC in reply to Harald Nordgren via GitGitGadget on lore

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

Show 9 quoted lines
> 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. 
Harald NordgrenOct 2, 2026, 13:57 UTC in reply to Ben Knoble on lore

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

Show 14 quoted lines
> > +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
Junio C HamanoOct 2, 2026, 14:47 UTC in reply to Harald Nordgren via GitGitGadget on lore

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

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 16 quoted lines
> 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'.

Back to recent threads