On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras
[off-list ref] wrote:

On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen [off-list ref] wrote:

quoted

On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
[off-list ref] wrote:

quoted

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 '~'.

quoted

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.

quoted

quoted

+'@'::
+  '@' 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