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

5 messages from 2006-05-21 to 2006-05-21. Participants: Shawn Pearce, Junio C Hamano, Eric Wong.
Thread: https://gitlist.dev/t/4226

## Shawn Pearce, 2006-05-21 01:37

Subject: [PATCH] Make '@' not valid in a ref name.
Message-ID: <20060521013751.GA7516@spearce.org>
URL: https://gitlist.dev/e/20060521013751.GA7516%40spearce.org

```
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
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

```

## Junio C Hamano, 2006-05-21 01:42

Subject: Re: [PATCH] Make '@' not valid in a ref name.
Message-ID: <7vodxsywzk.fsf@assigned-by-dhcp.cox.net>
URL: https://gitlist.dev/e/7vodxsywzk.fsf%40assigned-by-dhcp.cox.net
In-Reply-To: <20060521013751.GA7516@spearce.org>

```
I am not a fan of retroactively disallowing what we used to
allow.  Is this unavoidable?

```

## Shawn Pearce, 2006-05-21 01:58

Subject: Re: [PATCH] Make '@' not valid in a ref name.
Message-ID: <20060521015849.GB7605@spearce.org>
URL: https://gitlist.dev/e/20060521015849.GB7605%40spearce.org
In-Reply-To: <7vodxsywzk.fsf@assigned-by-dhcp.cox.net>

```
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, 2006-05-21 02:00

Subject: Re: [PATCH] Make '@' not valid in a ref name.
Message-ID: <20060521020038.GA22926@hand.yhbt.net>
URL: https://gitlist.dev/e/20060521020038.GA22926%40hand.yhbt.net
In-Reply-To: <20060521013751.GA7516@spearce.org>

```
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, 2006-05-21 02:19

Subject: Re: [PATCH] Make '@' not valid in a ref name.
Message-ID: <20060521021919.GA7700@spearce.org>
URL: https://gitlist.dev/e/20060521021919.GA7700%40spearce.org
In-Reply-To: <20060521020038.GA22926@hand.yhbt.net>

```
Eric Wong <normalperson@hand.yhbt.net> wrote:
> 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.

```