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

From: Harald Nordgren <[email protected]>

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

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

index 3fbfbd3d5f..68ce6f3dc2 100644
@@ -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

index 4eda8c8eac..6546685760 100644
@@ -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));
 }
 

index d868a08110..5a4f16867a 100755
@@ -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

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

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

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/[email protected]/ 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/[email protected]/,
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/[email protected]/

Unfortunately, we are getting 502 back X-<.

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/[email protected]/

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.

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

-Peff

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.

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 <[email protected]>.

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

https://lore.kernel.org/git/[email protected]/

And then it also links back to a different thread

<[email protected]>

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.

Thanks, I'll take a look!

Harald

From: Harald Nordgren <[email protected]>

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

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

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

index 3fbfbd3d5f..68ce6f3dc2 100644
@@ -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

index 4eda8c8eac..6546685760 100644
@@ -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));
 }
 

index d868a08110..5a4f16867a 100755
@@ -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

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

Harald

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