Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 21, 2009, 21:00 UTC
Message-ID: <7vab7eegls.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20090320004029.GX23521@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

Show 24 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Fri, 20 Mar 2009, Johannes Schindelin wrote:
>> 
>> > Just try this:
>> > 
>> > 	$ git checkout -b %helloworld
>> 
>> It gets worse.  Much worse.
>> 
>> Try this (triggered by a comment by Ilari on IRC):
>> 
>> 	$ git checkout -b '@{1}'
>> 
>> That _works_! WTH?
>
> '@' is not reserved.  Neither is '{' or '}'.  Neither is
> the combination.
>
> Waaaaaay back when I added reflog query syntax I tried to use only
> '@', people with branch names like 'foo@bar' made a point that they
> didn't want to reserve it.  We stuck the {} in as a "highly unlikely
> to conflict with a branch name" and others pointed out most shells
> will do fun things with those, but we kept it to avoid ambiguous
> meanings of "foo@noon" when foo@noon is already a branch.

Let's do something along this line.

-- >8 --
Subject: [PATCH] check_ref_format(): tighten refname rules

Yes, I know that tightening rules retroactively is bad, but this changes the rules for refnames to forbid:

 (1) a refname that ends with a dot.

     We already reject a path component that begins with a dot, primarily
     to avoid ambiguous range interpretation.  If we allowed ".B" as a
     valid ref, it is unclear if "A...B" means "in dot-B but not in A" or
     "either in A or B but not in both".

     But for this to be complete, we need also to forbid "A." to avoid "in
     B but not in A-dot".  This was not a problem in the original range
     notation, but we should have added this restriction when three-dot
     notation was introduced.

     Unlike "no dot at the beginning of any path component" rule, this
     rule does not have to be "no dot at the end of any path component",
     because you cannot abbreviate the tail end away, similar to you can
     say "dot-B" to mean "refs/heads/dot-B".

 (2) a refname that contains "@{" in it.

     Some people and foreign SCM converter may have named their branches
     as frotz@243 and we still want to keep supporting it, but "git branch
     @{1}" is a disaster.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 refs.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/refs.c b/refs.c
index 8d3c502..abd5623 100644
--- a/refs.c
+++ b/refs.c
@@ -693,7 +693,7 @@ static inline int bad_ref_char(int ch)
 
 int check_ref_format(const char *ref)
 {
-	int ch, level, bad_type;
+	int ch, level, bad_type, last;
 	int ret = CHECK_REF_FORMAT_OK;
 	const char *cp = ref;
 
@@ -717,19 +717,23 @@ int check_ref_format(const char *ref)
 				return CHECK_REF_FORMAT_ERROR;
 		}
 
+		last = ch;
 		/* scan the rest of the path component */
 		while ((ch = *cp++) != 0) {
 			bad_type = bad_ref_char(ch);
-			if (bad_type) {
+			if (bad_type)
 				return CHECK_REF_FORMAT_ERROR;
-			}
 			if (ch == '/')
 				break;
-			if (ch == '.' && *cp == '.')
+			if (last == '.' && ch == '.')
+				return CHECK_REF_FORMAT_ERROR;
+			if (last == '@' && ch == '{')
 				return CHECK_REF_FORMAT_ERROR;
 		}
 		level++;
 		if (!ch) {
+			if (ref <= cp - 2 && cp[-2] == '.')
+				return CHECK_REF_FORMAT_ERROR;
 			if (level < 2)
 				return CHECK_REF_FORMAT_ONELEVEL;
 			return ret;

-- 
1.6.2.1.299.gda643a