Re: [PATCH] Add new @ shortcut for HEAD
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Apr 30, 2013, 06:17 UTC
- Message-ID
- <CACsJy8BTj8Vb5dyJJXhAtQ4soUTAAshKATYB+f9X2p1n6VFHMQ@mail.gmail.com>
- In-Reply-To
- <CAMP44s35HcjZ0sMjbOxHZt96v8S8eEFF+Y9JF_K9FKnFe-S9Xg@mail.gmail.com>
On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Show 32 quoted lines
> On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> 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}.
>
> That's what I tried first, but it just didn't feel elegant to have one
> check for this case only. foo@ does follow naturally, and it doesn't
> hurt.
>
>>> +'@'::
>>> + '@' alone is a shortcut for 'HEAD'
>>> +
>>
>> And this does not explain about HEAD@ or master@. But because I prefer
>> the candy part only. This documentation part looks good :)
>
> Yeah, there's no point in documenting things that are not useful for
> the user. The fact that HEAD@ is translated to HEAD is just an
> implementation detail.Exactly. As it's implementation detail, it should not be exposed to user as "huh?" moments when they type "HEAD@". I'm may be paranoid, but if some user finds it nice (or just different) to try master@ in scripts, then we change implementation details and master@ no longer works, people could be upset. Undefined behavior syntax should be kept to minimum. And to answer your other mail regarding the harmlessness of @{-1}@, I'd rather pay some extra code than leave some loose ends like that. -- Duy