On Tue, Jan 14, 2014 at 03:45:27PM -0800, Junio C Hamano wrote:
> > Yet 'git check-ref-format --branch @mybranch@{u}'
> > claims @mybranch is an invalid branch name.
>
> I do not think it claims any such thing.
>
> $ git check-ref-format --branch @foo@{u}; echo $?
> fatal: '@foo@{u}' is not a valid branch name
> 128
> $ git check-ref-format --branch @foo; echo $?
> @foo
> 0
>
> The former asks "Is the string '@foo@{u}' a suitable name to give a
> branch?" and the answer is no. The latter asks the same question
> about the string '@foo', and the answer is yes.
Is that what "--branch" does? I have never used it, but the manpage
seems to suggest it is about _parsing_ (which, IMHO, means it probably
should have been an option to rev-parse, but that is another issue
altogether).
So a more interesting output than the above is:
$ git checkout -t -b @mybranch origin/master
Branch @mybranch set up to track remote branch master from origin.
Switched to a new branch '@mybranch'
$ git check-ref-format --branch @mybranch@{u}; echo $?
fatal: '@mybranch@{u}' is not a valid branch name
128
$ git check-ref-format --branch HEAD@{u}; echo $?
origin/master
0
So "check-ref-format --branch" does understand @{u} syntax. But it
doesn't like @mybranch@{u}. You can see the same problem with rev-parse:
$ git rev-parse --symbolic-full-name HEAD@{u}
refs/remotes/origin/master
$ git rev-parse --symbolic-full-name @mybranch@{u}
@mybranch@{u}
fatal: ambiguous argument '@mybranch@{u}': unknown revision or path
not in the working tree.
So I do think there is a bug. The interpret_branch_name parser somehow
gets confused by the "@" in the name.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html