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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 3, 2023, 16:51 UTC
Message-ID: <xmqqh6tw7vtu.fsf@gitster.g>
In-Reply-To: <CAFFOgCUs9d6wJDf3p-+8UkzXRSymCgBctGt+rP+k0CzZPp2LJw@mail.gmail.com>

Alexandre Garnier <zigarn@gmail.com> writes:

Show 7 quoted lines

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