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

Duy Nguyen [off-list ref] writes:

It's not hard to do. The below patch makes "." equivalent to HEAD and
".U" -> "@{u}". Refs are not supposed to have '.' at the beginning, so
it's easy ...

How is the equivalent of master..@{u} expressed?  master...U?  How is
it disambiguated from a symmetric difference between master and U?

There are reasons why some characters are forbidden from appearing
at certain places in refname component. Anybody who designs a new
syntax needs to think _why_.

The restriction that a @ in refname cannot be followed by { is for
the same kind of disambiguation.  I do not mind a way to spell HEAD
with shorter than 4 keystrokes, and as I said I suspect "@" may be
the least bad one among what people may come up with in this thread,
but I do not think we can explain it as "@ is a synonym to HEAD"
[*1*].  We need to see if we can make the explanation we will give
to end users is understandable.


[Footnote]

*1* I do not think "@ is a new synonym for HEAD" would not be a good
explanation.  Some questions you should ask yourselves to see why:

"git update-ref HEAD $commit" is accepted.  If @ is a synonym for
HEAD, "git update-ref @ $commit" should work exactly the same way,
but is it desirable?  Would we have $GIT_DIR/@ as the result?  How
about "git symbolic-ref"?  Would @@{4} and HEAD@{4} be the same?

On Tue, Apr 30, 2013 at 11:09 PM, Junio C Hamano [off-list ref] wrote:

Duy Nguyen [off-list ref] writes:

quoted

It's not hard to do. The below patch makes "." equivalent to HEAD and
".U" -> "@{u}". Refs are not supposed to have '.' at the beginning, so
it's easy ...

How is the equivalent of master..@{u} expressed?  master...U?  How is
it disambiguated from a symmetric difference between master and U?

There are reasons why some characters are forbidden from appearing
at certain places in refname component. Anybody who designs a new
syntax needs to think _why_.

I figured it had something to do with hidden filenames, not "..".
There's only one char left for ref alias, the leading forward slash.
But than opens another can of worms.. We could put still ref aliases
into the same ref namespace, with lower precedence that actual refs,
so no new syntax required.
--
Duy

Junio C Hamano wrote:

We need to see if we can make the explanation we will give
to end users is understandable.

I'll make an attempt.

@ can be used in two contexts:
1. When used without the {}, it means HEAD.
2. When used with a {}, it means what those three forms individually
mean.  @{} already implies HEAD: don't put an extra @.

I think it's the cleanest.

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()?

Junio C Hamano wrote:

"git update-ref HEAD $commit" is accepted.  If @ is a synonym for
HEAD, "git update-ref @ $commit" should work exactly the same way,
but is it desirable?

 Would we have $GIT_DIR/@ as the result?  How
about "git symbolic-ref"?

Yes, it is a valid refname that can be overridden [*1*].

Would @@{4} and HEAD@{4} be the same?

No.  Why should they?

[Footnotes]

*1*: In the current implementation, git update-ref fails.

On Tue, Apr 30, 2013 at 12:23 PM, Ramkumar Ramachandra
[off-list ref] wrote:

Junio C Hamano wrote:

quoted

Would @@{4} and HEAD@{4} be the same?

No.  Why should they?

Why would HEAD^0^0~4 work? Because the syntax is recursive.

-- 
Felipe Contreras

Felipe Contreras wrote:

Why would HEAD^0^0~4 work? Because the syntax is recursive.

That's because you can compose with ^ and ^, while you can't with @
and @.  Does @{0}@{0} resolve?

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

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.
--
Duy