Hi!
I followed the example of ref '@{push}' in the documentation of
'rev-parse' (https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emltbranchnamegtpushemegemmasterpushemempushem)
and it doesn't work as documented.
Here is a way to reproduce:
# Setup
$ git init --bare origin.git
$ git clone --bare origin.git myfork.git
$ git clone origin.git local
$ cd local/
$ git commit --allow-empty -m init
$ git push origin
$ git remote add myfork ../myfork.git
# Check for
$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/main
$ git rev-parse --symbolic-full-name @{push}
refs/remotes/origin/main
# Follow doc's example
$ git config push.default current
$ git config remote.pushdefault myfork
$ git switch -c mybranch origin/main
$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/main
$ git rev-parse --symbolic-full-name @{push} # should be
refs/remotes/myfork/mybranch
@{push}
fatal: ambiguous argument '@{push}': unknown revision or path not in
the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
# Push is done with the expected remote, and only then the ref can be resolved
$ git push
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To ../myfork.git
* [new branch] mybranch -> mybranch
$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch
So it means the branch has to exist in the remote to resolve '@{push}'
as a symbolic ref?
I think I remember that a few years ago the example was working as-is
without the need to push.
If this is the expected behavior (not the best IMHO as it was a way to
check where it is going to be pushed before doing it), documentation
of the ref needs to be updated I think.
Regards,
--
Alex Garnier
