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

From: Thomas Rast <trast@inf.ethz.ch>
Date: May 1, 2013, 08:35 UTC
Message-ID: <87li7zcd3f.fsf@hexa.v.cablecom.net>
In-Reply-To: <CACsJy8CZ8E-ASmo237rRbYR7pqoseo-NpU6jVrg6Rvd9qSY01w@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 20 quoted lines

> On Wed, May 1, 2013 at 12:15 AM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
>> Duy Nguyen wrote:
>>> 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