[PATCH v3] Add new @ shortcut for HEAD

[PATCH v3] Add new @ shortcut for HEAD

[Felipe Contreras]

So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
can't remove '{0}'?

This patch allows '@' to be the same as 'HEAD'.

So now we can use 'git show @~1', and all that goody goodness.

Until now '@' was a valid name, but it conflicts with this idea, so lets
make it invalid. Probably very few people, if any, used this name.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---

Drop the last two patches of the previous series, and replace with this one,
which is the real deal ;)

 Documentation/git-check-ref-format.txt |  2 ++
 Documentation/revisions.txt            |  3 +++
 refs.c                                 |  4 ++++
 sha1_name.c                            | 17 +++++++++++++++++
 t/t1508-at-combinations.sh             |  3 +++
 5 files changed, 29 insertions(+)

diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index ec1739a..e8035ec 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -54,6 +54,8 @@ Git imposes the following rules on how references are named:
 
 . They cannot contain a sequence `@{`.
 
+. They cannot be the single character `@`.
+
 . They cannot contain a `\`.
 
 These rules make it easy for shell script based tools to parse
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index d477b3f..09896a3 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -58,6 +58,9 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.
 While the ref name encoding is unspecified, UTF-8 is preferred as
 some output processing may assume ref names in UTF-8.
 
+'@'::
+  '@' alone is a shortcut for 'HEAD'.
+
 '<refname>@\{<date>\}', e.g. 'master@\{yesterday\}', 'HEAD@\{5 minutes ago\}'::
   A ref followed by the suffix '@' with a date specification
   enclosed in a brace
diff --git a/refs.c b/refs.c
index de2d8eb..4e70b3e 100644
--- a/refs.c
+++ b/refs.c
@@ -72,6 +72,10 @@ int check_refname_format(const char *refname, int flags)
 {
 	int component_len, component_count = 0;
 
+	if (!strcmp(refname, "@"))
+		/* Refname is a single character '@'. */
+		return -1;
+
 	while (1) {
 		/* We are at the start of a path component. */
 		component_len = check_refname_component(refname, flags);
diff --git a/sha1_name.c b/sha1_name.c
index 76e3219..3b06e5e 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -965,6 +965,17 @@ int get_sha1_mb(const char *name, unsigned char *sha1)
 	return st;
 }
 
+/* parse @something syntax, when 'something' is not {.*} */
+static int interpret_empty_at(const char *name, int namelen, int len, struct strbuf *buf)
+{
+	if (len || name[1] == '{')
+		return -1;
+
+	strbuf_reset(buf);
+	strbuf_add(buf, "HEAD", 4);
+	return 1;
+}
+
 static int reinterpret(const char *name, int namelen, int len, struct strbuf *buf)
 {
 	/* we have extra data, which might need further processing */
@@ -1025,9 +1036,15 @@ int interpret_branch_name(const char *name, struct strbuf *buf)
 	cp = strchr(name, '@');
 	if (!cp)
 		return -1;
+
+	len = interpret_empty_at(name, namelen, cp - name, buf);
+	if (len > 0)
+		return reinterpret(name, namelen, len, buf);
+
 	tmp_len = upstream_mark(cp, namelen - (cp - name));
 	if (!tmp_len)
 		return -1;
+
 	len = cp + tmp_len - name;
 	cp = xstrndup(name, cp - name);
 	upstream = branch_get(*cp ? cp : NULL);
diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
index d5d6244..65584c0 100755
--- a/t/t1508-at-combinations.sh
+++ b/t/t1508-at-combinations.sh
@@ -45,6 +45,9 @@ check "@{u}" upstream-two
 check "@{u}@{1}" upstream-one
 check "@{-1}@{u}" master-two
 check "@{-1}@{u}@{1}" master-one
+check "@" new-two
+check "HEAD@{u}" upstream-two
+check "@@{u}" upstream-two
 nonsense "@{u}@{-1}"
 nonsense "@{1}@{u}"
 
-- 
1.8.3.rc0.399.gc96a135

Re: [PATCH v3] Add new @ shortcut for HEAD

[Eric Sunshine]

On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
> can't remove '{0}'?
>
> This patch allows '@' to be the same as 'HEAD'.
>
> So now we can use 'git show @~1', and all that goody goodness.
>
> Until now '@' was a valid name, but it conflicts with this idea, so lets

s/lets/let's/  (contraction of "let us")

> make it invalid. Probably very few people, if any, used this name.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>

Re: [PATCH v3] Add new @ shortcut for HEAD

[Thomas Adam]

On 1 May 2013 11:12, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
>> can't remove '{0}'?
>>
>> This patch allows '@' to be the same as 'HEAD'.
>>
>> So now we can use 'git show @~1', and all that goody goodness.
>>
>> Until now '@' was a valid name, but it conflicts with this idea, so lets
>
> s/lets/let's/  (contraction of "let us")

Ah, the contraction versus the first person singular.  In this case
where the context is concluding in decision, rather than making a
statement ("Let's go to the shops", for example) then "lets" is the
correct word to use here.

-- Thomas Adam

"lets" vs. "let's" (was: Re: [PATCH v3] Add new @ shortcut for HEAD)

[Marc Branchaud]

On 13-05-01 06:31 AM, Thomas Adam wrote:
> On 1 May 2013 11:12, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
>>> can't remove '{0}'?
>>>
>>> This patch allows '@' to be the same as 'HEAD'.
>>>
>>> So now we can use 'git show @~1', and all that goody goodness.
>>>
>>> Until now '@' was a valid name, but it conflicts with this idea, so lets
>>
>> s/lets/let's/  (contraction of "let us")
> 
> Ah, the contraction versus the first person singular.  In this case
> where the context is concluding in decision, rather than making a
> statement ("Let's go to the shops", for example) then "lets" is the
> correct word to use here.

You've lost me.  I think Eric is right.  If "lets" is a verb in this
sentence, what is its subject?

Besides, of which verb & tense is "lets" the first person singular?  Never
have I "lets" anything in my life...  :)

		M.

Re: "lets" vs. "let's"

[Junio C Hamano]

Marc Branchaud <mbranchaud@xiplink.com> writes:

> On 13-05-01 06:31 AM, Thomas Adam wrote:
>> On 1 May 2013 11:12, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras
>>> <felipe.contreras@gmail.com> wrote:
>>>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>>>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
>>>> can't remove '{0}'?
>>>>
>>>> This patch allows '@' to be the same as 'HEAD'.
>>>>
>>>> So now we can use 'git show @~1', and all that goody goodness.
>>>>
>>>> Until now '@' was a valid name, but it conflicts with this idea, so lets
>>>
>>> s/lets/let's/  (contraction of "let us")
>> 
>> Ah, the contraction versus the first person singular.  In this case
>> where the context is concluding in decision, rather than making a
>> statement ("Let's go to the shops", for example) then "lets" is the
>> correct word to use here.
>
> You've lost me.  I think Eric is right.  If "lets" is a verb in this
> sentence, what is its subject?
>
> Besides, of which verb & tense is "lets" the first person singular?  Never
> have I "lets" anything in my life...  :)

I'll queue with:

	... '@' was a valid name, but it conflicts with this idea,
	so make it invalid.

That is, just use the imperative mood to give an order to the
codebase to "make it so", which is a common style of log messages in
this project.

Re: [PATCH v3] Add new @ shortcut for HEAD

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
> can't remove '{0}'?
>
> This patch allows '@' to be the same as 'HEAD'.

While the above reasoning is cute, it is misleading.

If you start from HEAD@{1}~0^0, we can remove '^0', we can remove
'~0', but you cannot remove HEAD from the remaining "HEAD@{1}"
without changing what it means.  @{1} is where the current branch
was, while HEAD@{1} is where you were---they are different when you
have just did "git checkout anotherbranch".  HEAD@{1} is the tip of
your previous branch, @{1} is where anotherbranch was before its tip
became the commit you have checked out.

You have to be specially talking about "HEAD@{0}" as a whole for
that reasoning to hold; it does not work for HEAD@{$n} for an
arbitrary value of $n.

So I'd suggest toning it down, perhaps something like this:

	Even though we often can do without having to type "HEAD",
	e.g. "git log origin.." substitutes missing RHS with "HEAD",
	sometimes we still do need to type "HEAD" (thats six f*cking
	keystrokes "Caps Lock", "H", "E", "A", "D" and finally "Caps
	Lock").

        That is four keystrokes too many to name an often needed
	reference.  Make "@" usable as its synonym.

>
> So now we can use 'git show @~1', and all that goody goodness.
>
> Until now '@' was a valid name, but it conflicts with this idea, so lets
> make it invalid. Probably very few people, if any, used this name.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> diff --git a/sha1_name.c b/sha1_name.c
> index 76e3219..3b06e5e 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -965,6 +965,17 @@ int get_sha1_mb(const char *name, unsigned char *sha1)
>  	return st;
>  }
>  
> +/* parse @something syntax, when 'something' is not {.*} */
> +static int interpret_empty_at(const char *name, int namelen, int len, struct strbuf *buf)
> +{
> +	if (len || name[1] == '{')
> +		return -1;

This function is to handle a string that begins with '@', so by
definition len is zero when anything useful is done by it.  So...

> +	strbuf_reset(buf);
> +	strbuf_add(buf, "HEAD", 4);
> +	return 1;
> +}
> +
>  static int reinterpret(const char *name, int namelen, int len, struct strbuf *buf)
>  {
>  	/* we have extra data, which might need further processing */
> @@ -1025,9 +1036,15 @@ int interpret_branch_name(const char *name, struct strbuf *buf)
>  	cp = strchr(name, '@');
>  	if (!cp)
>  		return -1;
> +
> +	len = interpret_empty_at(name, namelen, cp - name, buf);

... it is suboptimal (from readability point of view) to have the
caller unconditionally call interpret_empty_at() when the function
clearly is marked to handle something that _begins_ with '@'.

I would suggest something like

	if (cp == name)
        	len = interpret_empty_at(name, namelen, buf);

which people may find much easier to follow.

For that matter, it may make even more sense to just remove the
"empty-at" function and inline its body here:

	if (cp == name && name[1] != '{') {
		strbuf_reset(buf);
                strbuf_add(buf, "HEAD", 4);
                len = 1;
        } else {
        	len = -1;
	}

> +	if (len > 0)
> +		return reinterpret(name, namelen, len, buf);
> +
>  	tmp_len = upstream_mark(cp, namelen - (cp - name));
>  	if (!tmp_len)
>  		return -1;
> +
>  	len = cp + tmp_len - name;
>  	cp = xstrndup(name, cp - name);
>  	upstream = branch_get(*cp ? cp : NULL);
> diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
> index d5d6244..65584c0 100755
> --- a/t/t1508-at-combinations.sh
> +++ b/t/t1508-at-combinations.sh
> @@ -45,6 +45,9 @@ check "@{u}" upstream-two
>  check "@{u}@{1}" upstream-one
>  check "@{-1}@{u}" master-two
>  check "@{-1}@{u}@{1}" master-one
> +check "@" new-two
> +check "HEAD@{u}" upstream-two
> +check "@@{u}" upstream-two
>  nonsense "@{u}@{-1}"
>  nonsense "@{1}@{u}"

Re: [PATCH v3] Add new @ shortcut for HEAD

[Felipe Contreras]

On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
>> can't remove '{0}'?
>>
>> This patch allows '@' to be the same as 'HEAD'.
>
> While the above reasoning is cute, it is misleading.
>
> If you start from HEAD@{1}~0^0, we can remove '^0', we can remove
> '~0', but you cannot remove HEAD from the remaining "HEAD@{1}"
> without changing what it means.  @{1} is where the current branch
> was, while HEAD@{1} is where you were---they are different when you
> have just did "git checkout anotherbranch".  HEAD@{1} is the tip of
> your previous branch, @{1} is where anotherbranch was before its tip
> became the commit you have checked out.

Replace @{1} with @{u} and it holds.

> You have to be specially talking about "HEAD@{0}" as a whole for
> that reasoning to hold; it does not work for HEAD@{$n} for an
> arbitrary value of $n.
>
> So I'd suggest toning it down, perhaps something like this:
>
>         Even though we often can do without having to type "HEAD",
>         e.g. "git log origin.." substitutes missing RHS with "HEAD",
>         sometimes we still do need to type "HEAD" (thats six f*cking
>         keystrokes "Caps Lock", "H", "E", "A", "D" and finally "Caps
>         Lock").

I don't know what RHS means, and I don't use caps lock :)

>         That is four keystrokes too many to name an often needed
>         reference.  Make "@" usable as its synonym.

Yeah, that's nice, but doesn't explain why "@", and why not something else.

>> So now we can use 'git show @~1', and all that goody goodness.
>>
>> Until now '@' was a valid name, but it conflicts with this idea, so lets
>> make it invalid. Probably very few people, if any, used this name.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>> diff --git a/sha1_name.c b/sha1_name.c
>> index 76e3219..3b06e5e 100644
>> --- a/sha1_name.c
>> +++ b/sha1_name.c
>> @@ -965,6 +965,17 @@ int get_sha1_mb(const char *name, unsigned char *sha1)
>>       return st;
>>  }
>>
>> +/* parse @something syntax, when 'something' is not {.*} */
>> +static int interpret_empty_at(const char *name, int namelen, int len, struct strbuf *buf)
>> +{
>> +     if (len || name[1] == '{')
>> +             return -1;
>
> This function is to handle a string that begins with '@', so by
> definition len is zero when anything useful is done by it.  So...
>
>> +     strbuf_reset(buf);
>> +     strbuf_add(buf, "HEAD", 4);
>> +     return 1;
>> +}
>> +
>>  static int reinterpret(const char *name, int namelen, int len, struct strbuf *buf)
>>  {
>>       /* we have extra data, which might need further processing */
>> @@ -1025,9 +1036,15 @@ int interpret_branch_name(const char *name, struct strbuf *buf)
>>       cp = strchr(name, '@');
>>       if (!cp)
>>               return -1;
>> +
>> +     len = interpret_empty_at(name, namelen, cp - name, buf);
>
> ... it is suboptimal (from readability point of view) to have the
> caller unconditionally call interpret_empty_at() when the function
> clearly is marked to handle something that _begins_ with '@'.
>
> I would suggest something like
>
>         if (cp == name)
>                 len = interpret_empty_at(name, namelen, buf);
>
> which people may find much easier to follow.

Why are we then doing:

  int len = interpret_nth_prior_checkout(name, buf);

This function also needs the string to begin with '@', but we don't
check that, we leave that to the function to let us know if it did
interpret it, or not.

> For that matter, it may make even more sense to just remove the
> "empty-at" function and inline its body here:
>
>         if (cp == name && name[1] != '{') {
>                 strbuf_reset(buf);
>                 strbuf_add(buf, "HEAD", 4);
>                 len = 1;
>         } else {
>                 len = -1;
>         }
>
>> +     if (len > 0)
>> +             return reinterpret(name, namelen, len, buf);
>> +

If you are going to do that, there's no need to check len separately.

	if (cp == name && name[1] != '{') {
		strbuf_reset(buf);
		strbuf_add(buf, "HEAD", 4);
		return reinterpret(name, namelen, 1, buf);
	}

But I think it's less readable.

Cheers.

-- 
Felipe Contreras

Re: [PATCH v3] Add new @ shortcut for HEAD

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
>>> can't remove '{0}'?
>>>
>>> This patch allows '@' to be the same as 'HEAD'.
>>
>> While the above reasoning is cute, it is misleading.
>>
>> If you start from HEAD@{1}~0^0, we can remove '^0', we can remove
>> '~0', but you cannot remove HEAD from the remaining "HEAD@{1}"
>> without changing what it means.  @{1} is where the current branch
>> was, while HEAD@{1} is where you were---they are different when you
>> have just did "git checkout anotherbranch".  HEAD@{1} is the tip of
>> your previous branch, @{1} is where anotherbranch was before its tip
>> became the commit you have checked out.
>
> Replace @{1} with @{u} and it holds.

Yes and no.  Starting from HEAD@{u}~0^0, we can remove ^0 and ~0,
and you remove HEAD from the remaining "HEAD@{u}" to get @{u} and
all of them still mean the same thing.  It is the other branch your
current branch is integrating with.

But that decomposition does not get you to HEAD which is the final
destination you want to reach.  As soon as you drop the remaining
{u}, it suddenly changes the meaning and start referring to the
current branch.

>> So I'd suggest toning it down, perhaps something like this:
>>
>>         Even though we often can do without having to type "HEAD",
>>         e.g. "git log origin.." substitutes missing RHS with "HEAD",
>>         sometimes we still do need to type "HEAD" (thats six f*cking
>>         keystrokes "Caps Lock", "H", "E", "A", "D" and finally "Caps
>>         Lock").
>
> I don't know what RHS means, and I don't use caps lock :)

"right hand side"?  You can say "Hold down Shift", H, E, A, D and
"Release Shift" ;-).

>>         That is four keystrokes too many to name an often needed
>>         reference.  Make "@" usable as its synonym.
>
> Yeah, that's nice, but doesn't explain why "@", and why not something else.

The thing is, HEAD@{0}~0^0 nor HEAD@{u}~0^0 is not a valid
explanation why it is "@", either.

But that does _not_ mean "@" is a good choice.  Nor the explanation
has to be based on the "starting from this and strip" progression.

"@" is already special and is familiar to users when specifying a
ref, and that is a good enough reason (you can of course say that in
the log message).

Re: [PATCH v3] Add new @ shortcut for HEAD

[Felipe Contreras]

On Wed, May 1, 2013 at 5:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>>>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
>>>> can't remove '{0}'?
>>>>
>>>> This patch allows '@' to be the same as 'HEAD'.
>>>
>>> While the above reasoning is cute, it is misleading.
>>>
>>> If you start from HEAD@{1}~0^0, we can remove '^0', we can remove
>>> '~0', but you cannot remove HEAD from the remaining "HEAD@{1}"
>>> without changing what it means.  @{1} is where the current branch
>>> was, while HEAD@{1} is where you were---they are different when you
>>> have just did "git checkout anotherbranch".  HEAD@{1} is the tip of
>>> your previous branch, @{1} is where anotherbranch was before its tip
>>> became the commit you have checked out.
>>
>> Replace @{1} with @{u} and it holds.
>
> Yes and no.  Starting from HEAD@{u}~0^0, we can remove ^0 and ~0,
> and you remove HEAD from the remaining "HEAD@{u}" to get @{u} and
> all of them still mean the same thing.  It is the other branch your
> current branch is integrating with.
>
> But that decomposition does not get you to HEAD which is the final
> destination you want to reach.  As soon as you drop the remaining
> {u}, it suddenly changes the meaning and start referring to the
> current branch.

Yeah, @something has different meaning depending on what that
'something' is. We could add @{this-branch} to mean this is basically
a no-op, and then we can do the HEAD@{this-branch}~0^0 reduction
straight-forwardly, but I think it's overkill to add a new idiom only
to prove a point.

At the end of the day the important thing is that @ is the same as
@something, except without the 'something' in there. That's why the
shortcut is @, and not '.', or '+', or '&', or any number of other
single characters we could have chosen.

>>> So I'd suggest toning it down, perhaps something like this:
>>>
>>>         Even though we often can do without having to type "HEAD",
>>>         e.g. "git log origin.." substitutes missing RHS with "HEAD",
>>>         sometimes we still do need to type "HEAD" (thats six f*cking
>>>         keystrokes "Caps Lock", "H", "E", "A", "D" and finally "Caps
>>>         Lock").
>>
>> I don't know what RHS means, and I don't use caps lock :)
>
> "right hand side"?  You can say "Hold down Shift", H, E, A, D and
> "Release Shift" ;-).

Yeah, but the point is that different people have different ways of
doing it. Even if it was 'head' it would be a burden.

>>>         That is four keystrokes too many to name an often needed
>>>         reference.  Make "@" usable as its synonym.
>>
>> Yeah, that's nice, but doesn't explain why "@", and why not something else.
>
> The thing is, HEAD@{0}~0^0 nor HEAD@{u}~0^0 is not a valid
> explanation why it is "@", either.

Let's pick '+' then. Or something else.

> But that does _not_ mean "@" is a good choice.  Nor the explanation
> has to be based on the "starting from this and strip" progression.
>
> "@" is already special and is familiar to users when specifying a
> ref, and that is a good enough reason (you can of course say that in
> the log message).

Exactly, because ref@something is used for operations on a ref. If
'ref' is missing, it only makes sense to use HEAD (or something like
that), and if 'something' is missing, it only makes sense to make it a
no-op, but since we don't want to forbid refs with names like
'master@'. That's the reason why '@' makes sense, and not any other
character.

Cheers.

-- 
Felipe Contreras

Re: [PATCH v3] Add new @ shortcut for HEAD

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> The thing is, HEAD@{0}~0^0 nor HEAD@{u}~0^0 is not a valid
> explanation why it is "@", either.
>
> But that does _not_ mean "@" is a good choice.  Nor the explanation

Arrgh.  It does not mean " '@' is a BAD choice ".  '@' _is_ good.
But the point is that the explanation does not have to be a
technically incorrect "strip this, strip that".

Re: [PATCH v3] Add new @ shortcut for HEAD

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Exactly, because ref@something is used for operations on a ref. If
> 'ref' is missing, it only makes sense to use HEAD (or something like
> that), and if 'something' is missing, it only makes sense to make it a
> no-op, but since we don't want to forbid refs with names like
> 'master@'. That's the reason why '@' makes sense, and not any other
> character.

Yes.  My typo made it look as if I meant to say '@' was a bad
choice, but we are in agreement that '@' is better than any other
random choice of single punctuation letter.

It is just the "strip this, strip that" explanation, which is not
technically correct, does _not_ have to be our justification for
picking '@' as a short-hand for HEAD.

Re: [PATCH v3] Add new @ shortcut for HEAD

[Felipe Contreras]

On Wed, May 1, 2013 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Exactly, because ref@something is used for operations on a ref. If
>> 'ref' is missing, it only makes sense to use HEAD (or something like
>> that), and if 'something' is missing, it only makes sense to make it a
>> no-op, but since we don't want to forbid refs with names like
>> 'master@'. That's the reason why '@' makes sense, and not any other
>> character.
>
> Yes.  My typo made it look as if I meant to say '@' was a bad
> choice, but we are in agreement that '@' is better than any other
> random choice of single punctuation letter.

Yeah, we agree.

> It is just the "strip this, strip that" explanation, which is not
> technically correct, does _not_ have to be our justification for
> picking '@' as a short-hand for HEAD.

The point is that it follows from @something -> @.

-- 
Felipe Contreras

Re: [PATCH v3] Add new @ shortcut for HEAD

[Felipe Contreras]

On Wed, May 1, 2013 at 6:14 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Wed, May 1, 2013 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:

>> It is just the "strip this, strip that" explanation, which is not
>> technically correct, does _not_ have to be our justification for
>> picking '@' as a short-hand for HEAD.
>
> The point is that it follows from @something -> @.

So my proposal is:

---
Typing 'HEAD' is tedious, especially when we can use '@' instead.

The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.

After this patch, we can use 'git show @~1', and all that goody goodness.

Until now '@' was a valid ref name, but it conflicts with this idea, so lets
make it invalid. Probably very few people, if any, used this symbolic ref.
---

-- 
Felipe Contreras

Re: [PATCH v3] Add new @ shortcut for HEAD

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Wed, May 1, 2013 at 6:14 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Wed, May 1, 2013 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>>> It is just the "strip this, strip that" explanation, which is not
>>> technically correct, does _not_ have to be our justification for
>>> picking '@' as a short-hand for HEAD.
>>
>> The point is that it follows from @something -> @.
>
> So my proposal is:
>
> ---
> Typing 'HEAD' is tedious, especially when we can use '@' instead.
>
> The reason for choosing '@' is that it follows naturally from the
> ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
> operation, and when we don't have those, it makes sens to assume
> 'HEAD'.
>
> After this patch, we can use 'git show @~1', and all that goody goodness.

That reads much better.