threads / patch / 4226

patchMake '@' not valid in a ref name.

Subject: [PATCH] Make '@' not valid in a ref name.

## tl;dr

5 messages between May 21, 2006 and May 21, 2006. Diffs are folded; open one to read it.

replies: 4people: 3as markdown or json

Shawn Pearce· May 21, 2006, 01:37 UTC · lore

Now that the sha1 expression syntax supports looking up a ref's value at a prior point in time through the '@' operator the '@' operator should not be permitted in a ref name.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
90d3212d5351d2f6c6ad33578c9f9df2e07af12e
 refs.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
90d3212d5351d2f6c6ad33578c9f9df2e07af12e
Show changes to refs.c +2 −2
diff --git a/refs.c b/refs.c
index eeb1196..2530c99 100644
--- a/refs.c
+++ b/refs.c
@@ -213,14 +213,14 @@ int get_ref_sha1(const char *ref, unsign
  *
  * - any path component of it begins with ".", or
  * - it has double dots "..", or
- * - it has ASCII control character, "~", "^", ":" or SP, anywhere, or
+ * - it has ASCII control character, "@", "~", "^", ":" or SP,
  * - it ends with a "/".
  */
 
 static inline int bad_ref_char(int ch)
 {
 	return (((unsigned) ch) <= ' ' ||
-		ch == '~' || ch == '^' || ch == ':' ||
+		ch == '@' || ch == '~' || ch == '^' || ch == ':' ||
 		/* 2.13 Pattern Matching Notation */
 		ch == '?' || ch == '*' || ch == '[');
 }

-- 
1.3.3.gfad60
Shawn Pearce· May 21, 2006, 01:58 UTC · re: Junio C Hamano · lore

Re: [PATCH] Make '@' not valid in a ref name.

Junio C Hamano <junkio@cox.net> wrote:
> I am not a fan of retroactively disallowing what we used to
> allow.  Is this unavoidable?
>

We're talking about it on #git right now. Someone actually uses refs like 'user@host/foo' and thus doesn't like this patch either.

We were talking about disallowing '@{' instead. Really its just '@{<some run that smells like a date}' at the end of the ref which would want to be disallowed; similiar to how ~ and ^ really only need to be disallowed near the end.

The date parser grabs '@{' not '@' so 'user@host/foo@{yesterday}' makes sense to it. But 'user@{host}/foo@{yesterday}' is going to cause problems as the date parser will attempt to evaluate 'host}/foo@{yesterday'. :-(

-- 
Shawn.
Eric Wong· May 21, 2006, 02:00 UTC · re: Shawn Pearce · lore

Re: [PATCH] Make '@' not valid in a ref name.

Shawn Pearce <spearce@spearce.org> wrote:
> Now that the sha1 expression syntax supports looking up a ref's
> value at a prior point in time through the '@' operator the '@'
> operator should not be permitted in a ref name.

This would break git-archimport (where email addresses are the first part of the branch/tag names).

-- 
Eric Wong
Shawn Pearce· May 21, 2006, 02:19 UTC · re: Eric Wong · lore

Re: [PATCH] Make '@' not valid in a ref name.

Eric Wong <normalperson@hand.yhbt.net> wrote:
Show 7 quoted lines
> Shawn Pearce <spearce@spearce.org> wrote:
> > Now that the sha1 expression syntax supports looking up a ref's
> > value at a prior point in time through the '@' operator the '@'
> > operator should not be permitted in a ref name.
> 
> This would break git-archimport (where email addresses are the first
> part of the branch/tag names).

OK, so this patch is quite unpopular and should never make it into GIT. I'm glad we have many eyes on this mailing list!

There was just a short conversation on #git about converting the sha1 expression evaluator into a split parser/interpreter model. The idea here would be to convert an expression such as

  HEAD@{yesterday}~3^{tree}
into a an expression tree such as (in LISP style):
  (peel-onion (walk-back 3 (date-spec yesterday (ref HEAD))))

with such a tree it is relatively easy to evaluate the expression, but its also easy to determine if a ref name is valid. Just pass it through the parser and see if you get back anything more complex then '(ref <input>)'.

Comments?
-- 
Shawn.

← back to recent threads