Re: [PATCH] refs.c: interpret @ as HEAD

Duy Nguyen [off-list ref] writes:

On Wed, May 1, 2013 at 12:15 AM, Ramkumar Ramachandra
[off-list ref] wrote:

quoted

Duy Nguyen wrote:

quoted

We could put still ref aliases
into the same ref namespace, with lower precedence that actual refs,
so no new syntax required.

Actually, ref-alises are the right way to solve the problem.
Recursive symref peeling is a bad idea: I can't take my aliases with
me, and they complicate unnecessarily.

Any thoughts on how to implement it?  Should it go as deep as
resolve_ref_unsafe()?

Depends on how you define ref alias. resolve_ref_unsafe allows you to
substitute one ref with another. Thomas was talking about substituting
part of extended sha-1 syntax (U -> @{u}) so it can't be done down
there. I still think get_sha1_with_context_1() is the right place.
Still not so sure how to handle when we have both alias "U" and
refs/heads/U.

Well, I'm not sure about the semantics that I want.  But so far I am
*pretty* sure that I don't want it to be parameterized / part of another
ref.

So I'm fine with looking at *just* the alias, and resolving that to a
SHA1, and going from there.  So assuming U = @{u} and H = HEAD, you'd be
allowed to say U^ or U..H but not HU or H@U or whatever contortionate
syntax that would need.

As for the collisions, not sure which one is better.  Probably having
the same semantics as command aliases would be less confusing, i.e.,
existing refs take precedence.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch