Re: [PATCH] Add new @ shortcut for HEAD

Duy Nguyen [off-list ref] writes:

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

Originally I was going to say the same, but after thinking about it
a bit more, I changed my mind.

If you accept only "@" but not "master@", that behaviour needs a
wrong world model to understand and justify (one of which is "@ is a
synonym for HEAD").  If your rule is "In $anything@{$n}, you can
drop {$n} when $n==0", then HEAD@{0} becomes HEAD@ and master@{0}
becomes master@, and @{0} becomes @ naturally.

We should make sure that the code rejects "git update-ref @ foo"
because that is "git update-ref @{0} ref", by the way.  I didn't
check with Felipe's patch.

quoted

+'@'::
+  '@' alone is a shortcut for 'HEAD'
+

I think this explanation sends a wrong message, hinting as if you
can expect "update-ref @ master", "symbolic-ref @ refs/heads/next"
etc. to do something sensible to HEAD.

Felipe's original justification in the log message "I want to drop
{0}" sounds closer to what is going on here.

Junio C Hamano wrote:

If you accept only "@" but not "master@", that behaviour needs a
wrong world model to understand and justify (one of which is "@ is a
synonym for HEAD").  If your rule is "In $anything@{$n}, you can
drop {$n} when $n==0", then HEAD@{0} becomes HEAD@ and master@{0}
becomes master@, and @{0} becomes @ naturally.

You're telling me how to get @ from @{0}, but not how to get @ from
HEAD.  @{0}@{4} is meaningless, but HEAD@{4} is meaningful.

Junio C Hamano wrote:

If you accept only "@" but not "master@", that behaviour needs a
wrong world model to understand and justify (one of which is "@ is a
synonym for HEAD").  If your rule is "In $anything@{$n}, you can
drop {$n} when $n==0", then HEAD@{0} becomes HEAD@ and master@{0}
becomes master@, and @{0} becomes @ naturally.

Besides, you're going in the wrong direction this time.  You are
trying to fit an explanation to something that is useless.  How is
master@ useful?

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

Duy Nguyen [off-list ref] writes:

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

Originally I was going to say the same, but after thinking about it
a bit more, I changed my mind.

If you accept only "@" but not "master@", that behaviour needs a
wrong world model to understand and justify (one of which is "@ is a
synonym for HEAD").  If your rule is "In $anything@{$n}, you can
drop {$n} when $n==0", then HEAD@{0} becomes HEAD@ and master@{0}
becomes master@, and @{0} becomes @ naturally.

We should make sure that the code rejects "git update-ref @ foo"
because that is "git update-ref @{0} ref", by the way.  I didn't
check with Felipe's patch.

Hmm, with or without my patch 'git update @ foo' does nothing, same
with 'git update blah foo'. No error, no non-zero exit code, just
doesn't do anything.

quoted

quoted

+'@'::
+  '@' alone is a shortcut for 'HEAD'
+

I think this explanation sends a wrong message, hinting as if you
can expect "update-ref @ master", "symbolic-ref @ refs/heads/next"
etc. to do something sensible to HEAD.

Why would it? This is Documentation/revisions.txt, 'update-ref' has
nothing to do with that.

This hints that the user can do "update-ref @" as much as the
paragraph below thins that that user can do "update-ref
master@{today}".

Cheers.

-- 
Felipe Contreras

On Tue, Apr 30, 2013 at 12:47:57PM -0500, Felipe Contreras wrote:

quoted

We should make sure that the code rejects "git update-ref @ foo"
because that is "git update-ref @{0} ref", by the way.  I didn't
check with Felipe's patch.

Hmm, with or without my patch 'git update @ foo' does nothing, same
with 'git update blah foo'. No error, no non-zero exit code, just
doesn't do anything.

Are you sure?

  $ git version
  git version 1.8.2

  $ git update-ref @ foo
  fatal: foo: not a valid SHA1

  $ git update-ref @ origin/master
  $ echo $?
  0
  $ cat .git/@
  89740333e8d398f1da701e9023675321bbb9a85b

-Peff

On Tue, Apr 30, 2013 at 12:56 PM, Jeff King [off-list ref] wrote:

On Tue, Apr 30, 2013 at 12:47:57PM -0500, Felipe Contreras wrote:

quoted

quoted

We should make sure that the code rejects "git update-ref @ foo"
because that is "git update-ref @{0} ref", by the way.  I didn't
check with Felipe's patch.

Hmm, with or without my patch 'git update @ foo' does nothing, same
with 'git update blah foo'. No error, no non-zero exit code, just
doesn't do anything.

Are you sure?

  $ git version
  git version 1.8.2

  $ git update-ref @ foo
  fatal: foo: not a valid SHA1

  $ git update-ref @ origin/master
  $ echo $?
  0
  $ cat .git/@
  89740333e8d398f1da701e9023675321bbb9a85b

Right. I don't know why I expected it to show in 'git show-ref'.

-- 
Felipe Contreras

Felipe Contreras wrote:

It's not. The same way master^0^0~4 is not useful, yet it's works;
it's a logical result from the syntax.

It's logical if you explain @ as a shortcut for @{0}, and make
@{0}@{1} resolve somehow [*1*].

[Footnotes]

*1*: The best I can do is @{0} is like a ref (while @{>0} are
revisions), but you can't update-ref or symbolic-ref it.  Kludgy,
don't you think?

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

Junio C Hamano wrote:

quoted

If you accept only "@" but not "master@", that behaviour needs a
wrong world model to understand and justify (one of which is "@ is a
synonym for HEAD").  If your rule is "In $anything@{$n}, you can
drop {$n} when $n==0", then HEAD@{0} becomes HEAD@ and master@{0}
becomes master@, and @{0} becomes @ naturally.

Besides, you're going in the wrong direction this time.  You are
trying to fit an explanation to something that is useless.  How is
master@ useful?

It's not. The same way master^0^0~4 is not useful, yet it's works;
it's a logical result from the syntax.

-- 
Felipe Contreras

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

Felipe Contreras wrote:

quoted

It's not. The same way master^0^0~4 is not useful, yet it's works;
it's a logical result from the syntax.

It's logical if you explain @ as a shortcut for @{0}, and make
@{0}@{1} resolve somehow [*1*].

But @{-1}@{1} does resolve, and so does @{u}@{1}. So @ would be a
shortcut of @{this ref}, a no-op on the ref.

-- 
Felipe Contreras