Re: [PATCH] Add new @ shortcut for HEAD
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 30, 2013, 19:42 UTC
- Message-ID
- <7vhaindcuk.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <7vppxcdjd1.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 21 quoted lines
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>>> use 'git show @~1', and all that goody goodness.
>>
>> I like this. I haven't spent a lot of time on thinking about
>> ambiguation. But I think we're safe there. '@' is not overloaded much
>> like ':', '^' or '~'.
>>
>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>>> 'master@'.
>>
>> I'm a bit reluctant to this. It looks like incomplete syntax to me as
>> '@' has always been followed by '{'. Can we have the lone '@' candy
>> but reject master@ and HEAD@? There's no actual gain in writing
>> master@ vs master@{0}.
>
> Originally I was going to say the same, but after thinking about it
> a bit more, I changed my mind.Let me change my mind once again ;-)
As @ has been a valid character in a ref, I think "git show master@" and "git show HEAD@" _should_ error out, not because they suffix 'master' and 'HEAD" in a funny way, but simply because there is no branch called 'master@' (i.e. 'git for-each-ref | grep master@' yields empty). After you run "git branch master@ master~26", you should see "git show master@" not to error out, because that is just the name of a branch with somewhat an unusual name.
And we can still have "git show @" to do "git show HEAD", based on a world model completely different from I (incorrectly) advocated in the message I am replying to.
The rule would be "You should be able to say '@' where-ever you currently say HEAD" (aka '@' is a short-hand for 'HEAD').
That means "git checout @" should work the same way as "git checkout HEAD", "git log @~4" would work the same way as "git log HEAD~4", "git update-ref @ $(git rev-parse master)" should update the HEAD without creating $GIT_DIR/@, etc.
You can't go any simpler than that rule, and there is no room for confusion if that rule is properly implemented.
Hmm?