{"thread":{"id":"59524","subject":"Revision ref '@{push}' not resolved as documented","startedAt":"2023-04-02T15:16:33Z","lastAt":"2023-04-03T16:51:45Z","messageCount":3,"participants":["Alexandre Garnier","Felipe Contreras","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"474662","messageId":"CAFFOgCUs9d6wJDf3p-+8UkzXRSymCgBctGt+rP+k0CzZPp2LJw@mail.gmail.com","threadId":"59524","inReplyTo":null,"subject":"Revision ref '@{push}' not resolved as documented","fromName":"Alexandre Garnier","fromEmail":"zigarn@gmail.com","sentAt":"2023-04-02T15:16:18Z","receivedAt":"2023-04-02T15:16:33Z","isPatch":false,"sender":{"key":"zigarn@gmail.com","avatar":"https://gravatar.com/avatar/a7916de623e2296b522dd0275b7e64e6d8eb8f6875c9b61c1a3f84498d43c750?d=mp&s=160"},"body":"Hi!\n\nI followed the example of ref '@{push}' in the documentation of\n'rev-parse' (https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emltbranchnamegtpushemegemmasterpushemempushem)\nand it doesn't work as documented.\nHere is a way to reproduce:\n\n# Setup\n$ git init --bare origin.git\n$ git clone --bare origin.git myfork.git\n$ git clone origin.git local\n$ cd local/\n$ git commit --allow-empty -m init\n$ git push origin\n$ git remote add myfork ../myfork.git\n\n# Check for\n$ git rev-parse --symbolic-full-name @{upstream}\nrefs/remotes/origin/main\n$ git rev-parse --symbolic-full-name @{push}\nrefs/remotes/origin/main\n\n# Follow doc's example\n$ git config push.default current\n$ git config remote.pushdefault myfork\n$ git switch -c mybranch origin/main\n$ git rev-parse --symbolic-full-name @{upstream}\nrefs/remotes/origin/main\n$ git rev-parse --symbolic-full-name @{push}  # should be\nrefs/remotes/myfork/mybranch\n@{push}\nfatal: ambiguous argument '@{push}': unknown revision or path not in\nthe working tree.\nUse '--' to separate paths from revisions, like this:\n'git <command> [<revision>...] -- [<file>...]'\n\n# Push is done with the expected remote, and only then the ref can be resolved\n$ git push\nTotal 0 (delta 0), reused 0 (delta 0), pack-reused 0\nTo ../myfork.git\n* [new branch] mybranch -> mybranch\n$ git rev-parse --symbolic-full-name @{push}\nrefs/remotes/myfork/mybranch\n\nSo it means the branch has to exist in the remote to resolve '@{push}'\nas a symbolic ref?\nI think I remember that a few years ago the example was working as-is\nwithout the need to push.\n\nIf this is the expected behavior (not the best IMHO as it was a way to\ncheck where it is going to be pushed before doing it), documentation\nof the ref needs to be updated I think.\n\nRegards,\n-- \nAlex Garnier\n"},{"id":"474664","messageId":"CAMP44s0ujDcosdU2yDz-o7G8aCswEkpTP=Bfnjgt+5p=D4iHJw@mail.gmail.com","threadId":"59524","inReplyTo":"CAFFOgCUs9d6wJDf3p-+8UkzXRSymCgBctGt+rP+k0CzZPp2LJw@mail.gmail.com","subject":"Re: Revision ref '@{push}' not resolved as documented","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2023-04-02T18:41:46Z","receivedAt":"2023-04-02T18:42:03Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Apr 2, 2023 at 10:41 AM Alexandre Garnier <zigarn@gmail.com> wrote:\n\n> # Push is done with the expected remote, and only then the ref can be resolved\n> $ git push\n> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0\n> To ../myfork.git\n> * [new branch] mybranch -> mybranch\n> $ git rev-parse --symbolic-full-name @{push}\n> refs/remotes/myfork/mybranch\n>\n> So it means the branch has to exist in the remote to resolve '@{push}'\n> as a symbolic ref?\n\nIt has to exist as a ref.\n\nThis is not just for @{push}, same with @{upstream}:\n\n% git config branch.master.merge refs/heads/foobar\n\nNow `master@{upstream}` doesn't work.\n\n> I think I remember that a few years ago the example was working as-is\n> without the need to push.\n\nYou don't need to push, you can fetch, but the remote ref has to\nexist, and I think it has always been that way.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"474692","messageId":"xmqqh6tw7vtu.fsf@gitster.g","threadId":"59524","inReplyTo":"CAFFOgCUs9d6wJDf3p-+8UkzXRSymCgBctGt+rP+k0CzZPp2LJw@mail.gmail.com","subject":"Re: Revision ref '@{push}' not resolved as documented","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-04-03T16:51:41Z","receivedAt":"2023-04-03T16:51:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexandre Garnier <zigarn@gmail.com> writes:\n\n> # Push is done with the expected remote, and only then the ref can be resolved\n> $ git push\n> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0\n> To ../myfork.git\n> * [new branch] mybranch -> mybranch\n> $ git rev-parse --symbolic-full-name @{push}\n> refs/remotes/myfork/mybranch\n\nThis one is expected.\n\nI think the root cause of this confusion is that the \"rev-parse\"\ncommand, even with \"--symbolic\" or \"--symbolic-full-name\", is still\nabout answering a question about an existing object name.  If\n\"rev-parse X\" fails because X does not spell a valid object name,\n\"rev-parse --symbolic-full-name X\" is designed to fail the same way.\n\nI am not sure how involved the implementation to change the above\ndesign to be offhand.  The general flow of rev-parse is to feed an\nend-user supplied string to the object-name layer and ask it to be\nturned into an object name, and \"--symbolic-full\" must be stopping\nthat flow after the original string is canonicalized (e.g. 'master'\nis turned into 'refs/heads/master') but before it is turned into an\nobject name, in order to be able to return 'refs/heads/master'.  I\nwould not be surprised if it wasn't to hard to special case the\n\"--symbolic\" request to yield an unborn branch name like you\nexpected, but it would change the semantics and breaks backward\ncompatibility, so care must be taken if anybody wants to pursue\nthis.\n\nThanks.\n\n\n"}]}