{"thread":{"id":"66428","subject":"[PATCH] object-name: accept @{p} as short for @{push}","startedAt":"2026-09-30T19:39:49Z","lastAt":"2026-10-02T14:47:27Z","messageCount":11,"participants":["Harald Nordgren via GitGitGadget","D. Ben Knoble","Junio C Hamano","Jeff King","Harald Nordgren","Ben Knoble"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"553745","messageId":"pull.2431.git.git.1790797186658.gitgitgadget@gmail.com","threadId":"66428","inReplyTo":null,"subject":"[PATCH] object-name: accept @{p} as short for @{push}","fromName":"Harald Nordgren via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-09-30T19:39:46Z","receivedAt":"2026-09-30T19:39:49Z","isPatch":true,"body":"From: Harald Nordgren \n\nTyping \"git log @{p}..\" fails with \"unknown revision\", even though\n\"@{u}\" works as the short form of \"@{upstream}\". Users who reach for\nthe one letter spelling of the push destination by analogy get an\nerror.\n\nAccept \"@{p}\" wherever \"@{push}\" is accepted, in any case, just like\n\"@{u}\".\n\nSigned-off-by: Harald Nordgren \n---\n object-name: accept @{p} as short for @{push}\n \n @{u} works as the short form of @{upstream}, but @{p} fails with\n \"unknown revision\". This makes @{p} resolve to the same branch as\n @{push}, in any case, and documents it next to @{u}.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2431%2FHaraldNordgren%2Fpush-shorthand-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2431/HaraldNordgren/push-shorthand-v1\nPull-Request: https://github.com/git/git/pull/2431\n\n Documentation/revisions.adoc | 2 +-\n object-name.c | 2 +-\n t/t1514-rev-parse-push.sh | 7 +++++++\n 3 files changed, 9 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/revisions.adoc b/Documentation/revisions.adoc\nindex 3fbfbd3d5f..68ce6f3dc2 100644\n--- a/Documentation/revisions.adoc\n+++ b/Documentation/revisions.adoc\n@@ -122,7 +122,7 @@ some output processing may assume ref names in UTF-8.\n `branch..remote`). B@{u} refers to the remote-tracking branch for\n the branch X taken from remote R, typically found at `refs/remotes/R/X`.\n \n-'[]@\\{push\\}', e.g. 'master@\\{push\\}', '@\\{push\\}'::\n+'[]@\\{push\\}', e.g. 'master@\\{push\\}', '@\\{p\\}'::\n The suffix '@\\{push}' reports the branch \"where we would push to\" if\n `git push` were run while `branchname` was checked out (or the current\n `HEAD` if no branchname is specified). Like for '@\\{upstream\\}', we report\ndiff --git a/object-name.c b/object-name.c\nindex 4eda8c8eac..6546685760 100644\n--- a/object-name.c\n+++ b/object-name.c\n@@ -657,7 +657,7 @@ static inline int upstream_mark(const char *string, int len)\n \n static inline int push_mark(const char *string, int len)\n {\n-\tconst char *suffix[] = { \"@{push}\" };\n+\tconst char *suffix[] = { \"@{push}\", \"@{p}\" };\n \treturn at_mark(string, len, suffix, ARRAY_SIZE(suffix));\n }\n \ndiff --git a/t/t1514-rev-parse-push.sh b/t/t1514-rev-parse-push.sh\nindex d868a08110..5a4f16867a 100755\n--- a/t/t1514-rev-parse-push.sh\n+++ b/t/t1514-rev-parse-push.sh\n@@ -60,6 +60,13 @@ test_expect_success '@{push} with pushremote defined' '\n \tresolve topic@{push} refs/remotes/other/topic\n '\n \n+test_expect_success '@{p} is short for @{push}' '\n+\ttest_config push.default current &&\n+\ttest_config branch.topic.pushremote other &&\n+\tresolve topic@{p} refs/remotes/other/topic &&\n+\tresolve topic@{P} refs/remotes/other/topic\n+'\n+\n test_expect_success '@{push} with push refspecs' '\n \ttest_config push.default nothing &&\n \ttest_config remote.origin.push refs/heads/*:refs/heads/magic/* &&\n\nbase-commit: a018953688f1b10bddf91bff8747068f5f4746a4\n-- \ngitgitgadget\n"},{"id":"553770","messageId":"CALnO6CBR0XJUJR=2e5kUM8Fk9aV5uz+QxajRpnFFVTEkFfJQ3Q@mail.gmail.com","threadId":"66428","inReplyTo":"pull.2431.git.git.1790797186658.gitgitgadget@gmail.com","subject":"Re: [PATCH] object-name: accept @{p} as short for @{push}","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-09-30T21:39:03Z","receivedAt":"2026-09-30T21:39:15Z","isPatch":true,"body":"On Wed, Sep 30, 2026 at 4:06 PM Harald Nordgren via GitGitGadget\n wrote:\n>\n> From: Harald Nordgren \n>\n> Typing \"git log @{p}..\" fails with \"unknown revision\", even though\n> \"@{u}\" works as the short form of \"@{upstream}\". Users who reach for\n> the one letter spelling of the push destination by analogy get an\n> error.\n>\n> Accept \"@{p}\" wherever \"@{push}\" is accepted, in any case, just like\n> \"@{u}\".\n\nI've oft wanted this. Though, I don't have a `p = push` (or `p =\npull`) alias set, because it could be short for either!\n\nThere's no \"@{pull}\", though, so that reasoning doesn't apply here.\n\nI have to wonder if there's an older discussion around these notations\nthat explains why one got shorthand and the other didn't?\n\n-- \nD. Ben Knoble\n"},{"id":"553771","messageId":"xmqqbj9e8kb3.fsf@gitster.g","threadId":"66428","inReplyTo":"CALnO6CBR0XJUJR=2e5kUM8Fk9aV5uz+QxajRpnFFVTEkFfJQ3Q@mail.gmail.com","subject":"Re: [PATCH] object-name: accept @{p} as short for @{push}","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-30T22:07:44Z","receivedAt":"2026-09-30T22:07:48Z","isPatch":true,"body":"\"D. Ben Knoble\" writes:\n\n> On Wed, Sep 30, 2026 at 4:06 PM Harald Nordgren via GitGitGadget\n> wrote:\n>>\n>> From: Harald Nordgren \n>>\n>> Typing \"git log @{p}..\" fails with \"unknown revision\", even though\n>> \"@{u}\" works as the short form of \"@{upstream}\". Users who reach for\n>> the one letter spelling of the push destination by analogy get an\n>> error.\n>>\n>> Accept \"@{p}\" wherever \"@{push}\" is accepted, in any case, just like\n>> \"@{u}\".\n>\n> I've oft wanted this. Though, I don't have a `p = push` (or `p =\n> pull`) alias set, because it could be short for either!\n>\n> There's no \"@{pull}\", though, so that reasoning doesn't apply here.\n\nInteresting thing to point out. Letting @{push} squat on @{p} would\nprevent us from adding @{pull} and anything that begins with 'p' in\nthe future (like 'previous', perhaps?).\n\n> I have to wonder if there's an older discussion around these notations\n> that explains why one got shorthand and the other didn't?\n\nBut we have lived with only two at_marks in the object name syntax,\nfor upstream and for push, and nothing else for quite some time.\nSo perhaps it is OK to assume that we do not have to worry about any\nnew ones in the future?\n\nDigging the history, @{upstream} came in 2010 and @{push} came in\n2015.\n\n@{u} existed since the inception of @{upstream}, as we can see in\nhttps://lore.kernel.org/git/20150331173740.GE18912@peff.net/ which\nis the first iteration of the patch set that added @{push}. It is\nunclear what was said during the review of v2 [*] but in the review\nof v3 https://lore.kernel.org/git/20150521045233.GA26507@peff.net/,\nnobody questioned the asymmetry between @{upstream} having a\nshort-and-sweet @{u} while @{push} lacked the corresponding @{p}.\n\nI do not know if that was because \"push\" was so short and easy to\ntype anyway?\n\n\n[Footnote]\n\n * https://public-inbox.org/git/?q=gmane:268185 would have given us\n a good way to find what thread Peff was referring to in the cover\n letter of v3 iteration:\n\n https://lore.kernel.org/git/20150521044429.GA5857@peff.net/\n\n Unfortunately, we are getting 502 back X-<.\n"},{"id":"553772","messageId":"20260930223906.GA763270@coredump.intra.peff.net","threadId":"66428","inReplyTo":"xmqqbj9e8kb3.fsf@gitster.g","subject":"Re: [PATCH] object-name: accept @{p} as short for @{push}","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-09-30T22:39:06Z","receivedAt":"2026-09-30T22:39:08Z","isPatch":true,"body":"On Wed, Sep 30, 2026 at 03:07:44PM -0700, Junio C Hamano wrote:\n\n> @{u} existed since the inception of @{upstream}, as we can see in\n> https://lore.kernel.org/git/20150331173740.GE18912@peff.net/ which\n> is the first iteration of the patch set that added @{push}. It is\n> unclear what was said during the review of v2 [*] but in the review\n> of v3 https://lore.kernel.org/git/20150521045233.GA26507@peff.net/,\n> nobody questioned the asymmetry between @{upstream} having a\n> short-and-sweet @{u} while @{push} lacked the corresponding @{p}.\n\nI think you have to go back further. Another contributor proposed\n@{publish} with somewhat different semantics, and I requested that it\nnot use @{p} to avoid confusion between the two. There was also some\ndiscussion of @{pull} (I think as an alias to @{upstream}) at the time,\nwhich would further increase the confusion.\n\nSee this what's cooking and the actual patch threads around that time:\n\n https://lore.kernel.org/git/xmqqoazpt45p.fsf@gitster.dls.corp.google.com/\n\nI don't remember what ultimately happened with the @{publish} series,\nbut given the time-frame and the contributor, I can make some guesses.\n\nI don't think either of those name conflicts are under current\ndiscussion, so I don't have any particular objection. Just noting the\nhistory.\n\n> * https://public-inbox.org/git/?q=gmane:268185 would have given us\n> a good way to find what thread Peff was referring to in the cover\n> letter of v3 iteration:\n> \n> https://lore.kernel.org/git/20150521044429.GA5857@peff.net/\n> \n> Unfortunately, we are getting 502 back X-<.\n\nI have a local archive, but the v2 thread is not enlightening. :)\n\n-Peff\n"},{"id":"553777","messageId":"xmqq7bk28i88.fsf@gitster.g","threadId":"66428","inReplyTo":"pull.2431.git.git.1790797186658.gitgitgadget@gmail.com","subject":"Re: [PATCH] object-name: accept @{p} as short for @{push}","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-30T22:52:39Z","receivedAt":"2026-09-30T22:52:43Z","isPatch":true,"body":"\"Harald Nordgren via GitGitGadget\" writes:\n\n> From: Harald Nordgren \n>\n> Typing \"git log @{p}..\" fails with \"unknown revision\", even though\n> \"@{u}\" works as the short form of \"@{upstream}\". Users who reach for\n> the one letter spelling of the push destination by analogy get an\n> error.\n\nThat's a weak justification. The same argument may lead to a\ndifferent conclusion, i.e., we should remove @{u}, for example ;-)\n\nAs I wrote in my response to Ben Knoble, I dug the mailing list\nhistory, and I think it is a good thing to record in the log message\nof this change what we can learn from the history. Things that you\nshould describe include \n\n - @{upstream} had @{u} from the beginning\n - @{push} did not\n - the reason we do not have corresponding @{p} is not because\n somebody gave a concrete reason why we shouldn't while the\n feature was being added.\n\nThe last one is, as Ben brought up, a very good thing to mention, as\nwe can justify this change with \"just for symmetry, add missing @{p}\".\n\nQueued.\n\n"},{"id":"553791","messageId":"xmqq1paa85e9.fsf@gitster.g","threadId":"66428","inReplyTo":"xmqqbj9e8kb3.fsf@gitster.g","subject":"Re: [PATCH] object-name: accept @{p} as short for @{push}","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-01T03:29:50Z","receivedAt":"2026-10-01T03:29:56Z","isPatch":true,"body":"Junio C Hamano writes:\n\n> [Footnote]\n>\n> * https://public-inbox.org/git/?q=gmane:268185 would have given us\n> a good way to find what thread Peff was referring to in the cover\n> letter of v3 iteration:\n>\n> https://lore.kernel.org/git/20150521044429.GA5857@peff.net/\n>\n> Unfortunately, we are getting 502 back X-<.\n\nWell, I remembered that gmane still offers nntp clients ;-)\n\nWe can visit nntp://news.gmane.io/gmane.comp.version-control.git/\nand ask for article #268185 to learn that the thread begins with\nthe message <20150501224414.GA25551@peff.net>.\n\nThat's 12-patch series of v2 that can be seen at lore:\n\nhttps://lore.kernel.org/git/20150501224414.GA25551@peff.net/\n\nAnd then it also links back to a different thread\n\n<1389126588-3663-1-git-send-email-artagnon@gmail.com>\n\nthat started @{publish} notation. In one of the messages in\nthe discussion thread, I see I was asking\n\n If @{u} can already be used for upstream, why not allow @{p} but\n require two letters @{pu}? Just being curious---I am not\n advocating strongly for a shorter short-hand.\n\nThe thread also has a fairly well written summary of what symmetric\nand triangular workflows are, and how Git 2.0 would give users\nchoice to select among three simplest models. The thread was\napparently from pre Git 2.0 days.\n"},{"id":"553813","messageId":"CAHwyqnV+63w6DcPm5ea0n8inqG_v4ujR2CiAbZr-h5SdZJsHOg@mail.gmail.com","threadId":"66428","inReplyTo":"xmqq7bk28i88.fsf@gitster.g","subject":"Re: [PATCH] object-name: accept @{p} as short for @{push}","fromName":"Harald Nordgren","fromEmail":"haraldnordgren@gmail.com","sentAt":"2026-10-01T07:05:06Z","receivedAt":"2026-10-01T07:05:45Z","isPatch":true,"body":"> > From: Harald Nordgren \n> >\n> > Typing \"git log @{p}..\" fails with \"unknown revision\", even though\n> > \"@{u}\" works as the short form of \"@{upstream}\". Users who reach for\n> > the one letter spelling of the push destination by analogy get an\n> > error.\n>\n> That's a weak justification. The same argument may lead to a\n> different conclusion, i.e., we should remove @{u}, for example ;-)\n>\n> As I wrote in my response to Ben Knoble, I dug the mailing list\n> history, and I think it is a good thing to record in the log message\n> of this change what we can learn from the history. Things that you\n> should describe include\n>\n> - @{upstream} had @{u} from the beginning\n> - @{push} did not\n> - the reason we do not have corresponding @{p} is not because\n> somebody gave a concrete reason why we shouldn't while the\n> feature was being added.\n>\n> The last one is, as Ben brought up, a very good thing to mention, as\n> we can justify this change with \"just for symmetry, add missing @{p}\".\n\nThanks, I'll take a look!\n\n\nHarald\n"},{"id":"553906","messageId":"pull.2431.v2.git.git.1790927399813.gitgitgadget@gmail.com","threadId":"66428","inReplyTo":"pull.2431.git.git.1790797186658.gitgitgadget@gmail.com","subject":"[PATCH v2] object-name: accept @{p} as short for @{push}","fromName":"Harald Nordgren via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-10-02T07:49:59Z","receivedAt":"2026-10-02T07:50:02Z","isPatch":true,"body":"From: Harald Nordgren \n\n\"git log @{p}\" fails with \"unknown revision\", even though \"@{u}\"\nworks for \"@{upstream}\".\n\nThe \"@{upstream}\" notation came with its \"@{u}\" short form from the\nvery beginning in 28fb84382b (Introduce @{upstream} notation,\n2009-09-10). When \"@{push}\" was added in adfe5d0434 (sha1_name:\nimplement @{push} shorthand, 2015-05-21), \"@{p}\" was held back to\navoid confusion with a proposed \"@{publish}\" and talk of an \"@{pull}\".\nNeither of those was ever added.\n\nAdd the missing \"@{p}\" for symmetry with \"@{u}\".\n\nSigned-off-by: Harald Nordgren \n---\n object-name: accept @{p} as short for @{push}\n \n @{u} works as the short form of @{upstream}, but @{p} fails with\n \"unknown revision\". This makes @{p} resolve to the same branch as\n @{push}, in any case, and documents it next to @{u}.\n \n Changes in v2:\n \n * Commit message explains history.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2431%2FHaraldNordgren%2Fpush-shorthand-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2431/HaraldNordgren/push-shorthand-v2\nPull-Request: https://github.com/git/git/pull/2431\n\nRange-diff vs v1:\n\n 1: f772f79954 ! 1: 1097f119a3 object-name: accept @{p} as short for @{push}\n @@ Metadata\n ## Commit message ##\n object-name: accept @{p} as short for @{push}\n \n - Typing \"git log @{p}..\" fails with \"unknown revision\", even though\n - \"@{u}\" works as the short form of \"@{upstream}\". Users who reach for\n - the one letter spelling of the push destination by analogy get an\n - error.\n + \"git log @{p}\" fails with \"unknown revision\", even though \"@{u}\"\n + works for \"@{upstream}\".\n \n - Accept \"@{p}\" wherever \"@{push}\" is accepted, in any case, just like\n - \"@{u}\".\n + The \"@{upstream}\" notation came with its \"@{u}\" short form from the\n + very beginning in 28fb84382b (Introduce @{upstream} notation,\n + 2009-09-10). When \"@{push}\" was added in adfe5d0434 (sha1_name:\n + implement @{push} shorthand, 2015-05-21), \"@{p}\" was held back to\n + avoid confusion with a proposed \"@{publish}\" and talk of an \"@{pull}\".\n + Neither of those was ever added.\n +\n + Add the missing \"@{p}\" for symmetry with \"@{u}\".\n \n Signed-off-by: Harald Nordgren \n \n\n\n Documentation/revisions.adoc | 2 +-\n object-name.c | 2 +-\n t/t1514-rev-parse-push.sh | 7 +++++++\n 3 files changed, 9 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/revisions.adoc b/Documentation/revisions.adoc\nindex 3fbfbd3d5f..68ce6f3dc2 100644\n--- a/Documentation/revisions.adoc\n+++ b/Documentation/revisions.adoc\n@@ -122,7 +122,7 @@ some output processing may assume ref names in UTF-8.\n `branch..remote`). B@{u} refers to the remote-tracking branch for\n the branch X taken from remote R, typically found at `refs/remotes/R/X`.\n \n-'[]@\\{push\\}', e.g. 'master@\\{push\\}', '@\\{push\\}'::\n+'[]@\\{push\\}', e.g. 'master@\\{push\\}', '@\\{p\\}'::\n The suffix '@\\{push}' reports the branch \"where we would push to\" if\n `git push` were run while `branchname` was checked out (or the current\n `HEAD` if no branchname is specified). Like for '@\\{upstream\\}', we report\ndiff --git a/object-name.c b/object-name.c\nindex 4eda8c8eac..6546685760 100644\n--- a/object-name.c\n+++ b/object-name.c\n@@ -657,7 +657,7 @@ static inline int upstream_mark(const char *string, int len)\n \n static inline int push_mark(const char *string, int len)\n {\n-\tconst char *suffix[] = { \"@{push}\" };\n+\tconst char *suffix[] = { \"@{push}\", \"@{p}\" };\n \treturn at_mark(string, len, suffix, ARRAY_SIZE(suffix));\n }\n \ndiff --git a/t/t1514-rev-parse-push.sh b/t/t1514-rev-parse-push.sh\nindex d868a08110..5a4f16867a 100755\n--- a/t/t1514-rev-parse-push.sh\n+++ b/t/t1514-rev-parse-push.sh\n@@ -60,6 +60,13 @@ test_expect_success '@{push} with pushremote defined' '\n \tresolve topic@{push} refs/remotes/other/topic\n '\n \n+test_expect_success '@{p} is short for @{push}' '\n+\ttest_config push.default current &&\n+\ttest_config branch.topic.pushremote other &&\n+\tresolve topic@{p} refs/remotes/other/topic &&\n+\tresolve topic@{P} refs/remotes/other/topic\n+'\n+\n test_expect_success '@{push} with push refspecs' '\n \ttest_config push.default nothing &&\n \ttest_config remote.origin.push refs/heads/*:refs/heads/magic/* &&\n\nbase-commit: a018953688f1b10bddf91bff8747068f5f4746a4\n-- \ngitgitgadget\n"},{"id":"553959","messageId":"81BD7B8C-6E7E-451A-9D48-49ABD5FA5F68@gmail.com","threadId":"66428","inReplyTo":"pull.2431.v2.git.git.1790927399813.gitgitgadget@gmail.com","subject":"Re: [PATCH v2] object-name: accept @{p} as short for @{push}","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-10-02T12:08:59Z","receivedAt":"2026-10-02T12:09:11Z","isPatch":true,"body":"\n> Le 2 oct. 2026 à 03:50, Harald Nordgren via GitGitGadget a écrit :\n> \n> +test_expect_success '@{p} is short for @{push}' '\n> + test_config push.default current &&\n> + test_config branch.topic.pushremote other &&\n> + resolve topic@{p} refs/remotes/other/topic &&\n> + resolve topic@{P} refs/remotes/other/topic\n> +'\n> +\n\nI don’t recall offhand if @{U} case-variant is supported, but I wonder\nif we might not want to preserve as many single-character shorthands\nas we can, since there are a limited number that are reasonable to\ntype.\n\nIf upstream already supports different cases, though, symmetry is probably best. "},{"id":"553966","messageId":"CAHwyqnV4KzDvqeSt-t6NUyV8L3pkstdYNP9itNKLS2guQ0yJuQ@mail.gmail.com","threadId":"66428","inReplyTo":"81BD7B8C-6E7E-451A-9D48-49ABD5FA5F68@gmail.com","subject":"Re: [PATCH v2] object-name: accept @{p} as short for @{push}","fromName":"Harald Nordgren","fromEmail":"haraldnordgren@gmail.com","sentAt":"2026-10-02T13:57:45Z","receivedAt":"2026-10-02T13:58:25Z","isPatch":true,"body":"> > +test_expect_success '@{p} is short for @{push}' '\n> > + test_config push.default current &&\n> > + test_config branch.topic.pushremote other &&\n> > + resolve topic@{p} refs/remotes/other/topic &&\n> > + resolve topic@{P} refs/remotes/other/topic\n> > +'\n> > +\n>\n> I don’t recall offhand if @{U} case-variant is supported, but I wonder\n> if we might not want to preserve as many single-character shorthands\n> as we can, since there are a limited number that are reasonable to\n> type.\n>\n> If upstream already supports different cases, though, symmetry is probably best.\n\nIt surprised me too, but '@{U}' is actually supported already.\n\n\nHarald\n"},{"id":"553972","messageId":"xmqqse2o17np.fsf@gitster.g","threadId":"66428","inReplyTo":"pull.2431.v2.git.git.1790927399813.gitgitgadget@gmail.com","subject":"Re: [PATCH v2] object-name: accept @{p} as short for @{push}","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-02T14:47:22Z","receivedAt":"2026-10-02T14:47:27Z","isPatch":true,"body":"\"Harald Nordgren via GitGitGadget\" writes:\n\n> From: Harald Nordgren \n>\n> \"git log @{p}\" fails with \"unknown revision\", even though \"@{u}\"\n> works for \"@{upstream}\".\n>\n> The \"@{upstream}\" notation came with its \"@{u}\" short form from the\n> very beginning in 28fb84382b (Introduce @{upstream} notation,\n> 2009-09-10). When \"@{push}\" was added in adfe5d0434 (sha1_name:\n> implement @{push} shorthand, 2015-05-21), \"@{p}\" was held back to\n> avoid confusion with a proposed \"@{publish}\" and talk of an \"@{pull}\".\n> Neither of those was ever added.\n>\n> Add the missing \"@{p}\" for symmetry with \"@{u}\".\n>\n> Signed-off-by: Harald Nordgren \n> ---\n\nVery well written. Thanks. Let me mark it for 'next'.\n"}]}