Revision ref '@{push}' not resolved as documented

Revision ref '@{push}' not resolved as documented

[Alexandre Garnier]

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

Re: Revision ref '@{push}' not resolved as documented

[Felipe Contreras]

On Sun, Apr 2, 2023 at 10:41 AM Alexandre Garnier <zigarn@gmail.com> wrote:

> # 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?

It has to exist as a ref.

This is not just for @{push}, same with @{upstream}:

% git config branch.master.merge refs/heads/foobar

Now `master@{upstream}` doesn't work.

> I think I remember that a few years ago the example was working as-is
> without the need to push.

You don't need to push, you can fetch, but the remote ref has to
exist, and I think it has always been that way.

Cheers.

-- 
Felipe Contreras

Re: Revision ref '@{push}' not resolved as documented

[Junio C Hamano]

Alexandre Garnier <zigarn@gmail.com> writes:

> # 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

This one is expected.

I think the root cause of this confusion is that the "rev-parse"
command, even with "--symbolic" or "--symbolic-full-name", is still
about answering a question about an existing object name.  If
"rev-parse X" fails because X does not spell a valid object name,
"rev-parse --symbolic-full-name X" is designed to fail the same way.

I am not sure how involved the implementation to change the above
design to be offhand.  The general flow of rev-parse is to feed an
end-user supplied string to the object-name layer and ask it to be
turned into an object name, and "--symbolic-full" must be stopping
that flow after the original string is canonicalized (e.g. 'master'
is turned into 'refs/heads/master') but before it is turned into an
object name, in order to be able to return 'refs/heads/master'.  I
would not be surprised if it wasn't to hard to special case the
"--symbolic" request to yield an unborn branch name like you
expected, but it would change the semantics and breaks backward
compatibility, so care must be taken if anybody wants to pursue
this.

Thanks.