I couldn't find a duplicate in the JIRA instance.
According to the documentation of check-ref-format, a branch name such
as @mybranch is valid. Yet 'git check-ref-format --branch @mybranch@{u}'
claims @mybranch is an invalid branch name. yet I am able to create the
branch (which would seem the obvious place to check for an invalid
branch name)
Pick any repository with an upstream remote (I cloned git itself from
github). The following will reproduce the bug
> $cd ~/play/gitsrc/
> $
> $git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
>
> nothing to commit, working directory clean
> $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 branch -av
> * @mybranch 14598b9 Sync with 1.8.5.3
> master 14598b9 Sync with 1.8.5.3
> remotes/origin/HEAD -> origin/master
> remotes/origin/maint 4224916 Git 1.8.5.3
> remotes/origin/master 14598b9 Sync with 1.8.5.3
> remotes/origin/next b139ac2 Sync with master
> remotes/origin/pu 3d58c42 Merge branch 'ab/subtree-doc' into pu
> remotes/origin/todo 1066e10 What's cooking (2014/01 #02)
> $git check-ref-format --branch @mybranch
> @mybranch
> $git check-ref-format --branch @mybranch@{u}
> fatal: '@mybranch@{u}' is not a valid branch name
> $git rev-parse --abbrev-ref @mybranch
> @mybranch
> $git rev-parse --abbrev-ref @mybranch@{u}
> @mybranch@{u}
> fatal: ambiguous argument '@mybranch@{u}': unknown revision or path
> not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'
> $
The same problem appears if the single '@' is anywhere in the branch name.
I *think* the problem lies in 'interpret_empty_at' in sha1_name.c with
these statements
> if (next != name + 1)
> return -1;
Which is trying to allow the sequence '@@' but I'm not certain enough of
unintended consequences to suggest a patch.
In our real-world example, we wanted to use a naming convention where a
branch name beginning with @ was intended to be a long-lived branch (for
example, a support branch for an official release). Thus, our sequence
above actually begins with something like 'git checkout -t
origin/@release1'.
We hit this problem some considerable time after initiating the naming
convention, so it's too late to turn back for us.
As a work around, if you have the branch checked out, then using HEAD
instead of the branch name works
> $git checkout @mybranch
> Switched to branch '@mybranch'
> Your branch is up-to-date with 'origin/master'.
> $git check-ref-format --branch HEAD@{u}
> origin/master
> $git rev-parse --abbrev-ref HEAD@{u}
> origin/master
> $
Envronment:
> $git version
> git version 1.8.5.2
> $lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 12.04.3 LTS
> Release: 12.04
> Codename: precise
Keith Derrick
--
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