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

[Junio C Hamano <gitster@pobox.com>]

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.