Re: [PATCH] refs.c: interpret @ as HEAD
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 30, 2013, 16:09 UTC
- Message-ID
- <7vehdsf19m.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130430150430.GA13398@lanh>
Duy Nguyen <pclouds@gmail.com> 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?