From: Keith Derrick <keith.derrick@lge.com>
To: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: BUG: check-ref-format and rev-parse can not handle branches with an @ in their name combined with @{u}
Date: Tue, 14 Jan 2014 18:04:54 -0500 [thread overview]
Message-ID: <52D5C296.7050906@lge.com> (raw)
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
next reply other threads:[~2014-01-14 23:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 23:04 Keith Derrick [this message]
2014-01-14 23:45 ` BUG: check-ref-format and rev-parse can not handle branches with an @ in their name combined with @{u} Junio C Hamano
2014-01-15 5:00 ` Jeff King
2014-01-15 7:46 ` Junio C Hamano
2014-01-15 7:47 ` Jeff King
2014-01-15 8:25 ` [PATCH 0/5] interpret_branch_name bug potpourri Jeff King
2014-01-15 8:26 ` [PATCH 1/5] interpret_branch_name: factor out upstream handling Jeff King
2014-01-15 8:27 ` [PATCH 2/5] interpret_branch_name: rename "cp" variable to "at" Jeff King
2014-01-15 8:31 ` [PATCH 3/5] interpret_branch_name: always respect "namelen" parameter Jeff King
2014-01-15 8:37 ` [PATCH 4/5] interpret_branch_name: avoid @{upstream} past colon Jeff King
2014-01-15 8:40 ` [PATCH 5/5] interpret_branch_name: find all possible @-marks Jeff King
2014-01-15 21:03 ` [PATCH 0/5] interpret_branch_name bug potpourri Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52D5C296.7050906@lge.com \
--to=keith.derrick@lge.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).