threads / patch / 33693

v3Add new @ shortcut for HEAD

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

## tl;dr

14 messages between May 1, 2013 and May 6, 2013. Diffs are folded; open one to read it.

replies: 13people: 5as markdown or json

Felipe Contreras· May 1, 2013, 09:51 UTC · lore

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(+)
Show changes to 5 files +29 −0

Documentation/git-check-ref-format.txt, Documentation/revisions.txt, refs.c, sha1_name.c, t/t1508-at-combinations.sh

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
Eric Sunshine· May 1, 2013, 10:12 UTC · re: Felipe Contreras · lore

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

On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 9 quoted lines
> 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>
Thomas Adam· May 1, 2013, 10:31 UTC · re: Eric Sunshine · lore

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

On 1 May 2013 11:12, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 13 quoted lines
> 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
Marc Branchaud· May 1, 2013, 14:23 UTC · re: Thomas Adam · lore

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

On 13-05-01 06:31 AM, Thomas Adam wrote:
Show 19 quoted lines
> 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.
Junio C Hamano· May 1, 2013, 17:18 UTC · re: Marc Branchaud · lore

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

Marc Branchaud <mbranchaud@xiplink.com> writes:
Show 26 quoted lines
> 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.

Junio C Hamano· May 1, 2013, 17:53 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 5 quoted lines
> 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.
Show 21 quoted lines
>
> 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...

Show 14 quoted lines
> +	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;
	}
Show 23 quoted lines
> +	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}"
Felipe Contreras· May 1, 2013, 18:33 UTC · re: Junio C Hamano · lore

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

On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 17 quoted lines
> 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.
Show 11 quoted lines
> 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.
Show 49 quoted lines
>> 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.

Show 14 quoted lines
> 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
Junio C Hamano· May 1, 2013, 22:08 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 20 quoted lines
> 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.

Show 9 quoted lines
>> 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).

Felipe Contreras· May 1, 2013, 22:35 UTC · re: Junio C Hamano · lore

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

On Wed, May 1, 2013 at 5:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 32 quoted lines
> 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.

Show 12 quoted lines
>>> 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.

Show 7 quoted lines
>>>         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.
Show 6 quoted lines
> 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
Junio C Hamano· May 1, 2013, 22:59 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 6 quoted lines
> 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.

Felipe Contreras· May 1, 2013, 23:14 UTC · re: Junio C Hamano · lore

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

On Wed, May 1, 2013 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> 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
Felipe Contreras· May 2, 2013, 02:33 UTC · re: Felipe Contreras · lore

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

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:
Show 5 quoted lines
>> 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
Junio C Hamano· May 6, 2013, 14:48 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 21 quoted lines
> 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.
Junio C Hamano· May 1, 2013, 22:56 UTC · re: Junio C Hamano · lore

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

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

← back to recent threads