{"thread":{"id":"33693","subject":"[PATCH v3] Add new @ shortcut for HEAD","startedAt":"2013-05-01T09:51:28Z","lastAt":"2013-05-06T14:48:44Z","messageCount":14,"participants":["Felipe Contreras","Eric Sunshine","Thomas Adam","Marc Branchaud","Junio C Hamano"],"isPatch":true,"patchVersion":3,"patchTotal":null},"messages":[{"id":"216130","messageId":"1367401888-21055-1-git-send-email-felipe.contreras@gmail.com","threadId":"33693","inReplyTo":null,"subject":"[PATCH v3] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-01T09:51:28Z","receivedAt":"2013-05-01T09:51:28Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can\nremove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we\ncan't remove '{0}'?\n\nThis patch allows '@' to be the same as 'HEAD'.\n\nSo now we can use 'git show @~1', and all that goody goodness.\n\nUntil now '@' was a valid name, but it conflicts with this idea, so lets\nmake it invalid. Probably very few people, if any, used this name.\n\nSigned-off-by: Felipe Contreras \n---\n\nDrop the last two patches of the previous series, and replace with this one,\nwhich is the real deal ;)\n\n Documentation/git-check-ref-format.txt | 2 ++\n Documentation/revisions.txt | 3 +++\n refs.c | 4 ++++\n sha1_name.c | 17 +++++++++++++++++\n t/t1508-at-combinations.sh | 3 +++\n 5 files changed, 29 insertions(+)\n\ndiff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt\nindex ec1739a..e8035ec 100644\n--- a/Documentation/git-check-ref-format.txt\n+++ b/Documentation/git-check-ref-format.txt\n@@ -54,6 +54,8 @@ Git imposes the following rules on how references are named:\n \n . They cannot contain a sequence `@{`.\n \n+. They cannot be the single character `@`.\n+\n . They cannot contain a `\\`.\n \n These rules make it easy for shell script based tools to parse\ndiff --git a/Documentation/revisions.txt b/Documentation/revisions.txt\nindex d477b3f..09896a3 100644\n--- a/Documentation/revisions.txt\n+++ b/Documentation/revisions.txt\n@@ -58,6 +58,9 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.\n While the ref name encoding is unspecified, UTF-8 is preferred as\n some output processing may assume ref names in UTF-8.\n \n+'@'::\n+ '@' alone is a shortcut for 'HEAD'.\n+\n '@\\{\\}', e.g. 'master@\\{yesterday\\}', 'HEAD@\\{5 minutes ago\\}'::\n A ref followed by the suffix '@' with a date specification\n enclosed in a brace\ndiff --git a/refs.c b/refs.c\nindex de2d8eb..4e70b3e 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -72,6 +72,10 @@ int check_refname_format(const char *refname, int flags)\n {\n \tint component_len, component_count = 0;\n \n+\tif (!strcmp(refname, \"@\"))\n+\t\t/* Refname is a single character '@'. */\n+\t\treturn -1;\n+\n \twhile (1) {\n \t\t/* We are at the start of a path component. */\n \t\tcomponent_len = check_refname_component(refname, flags);\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 76e3219..3b06e5e 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -965,6 +965,17 @@ int get_sha1_mb(const char *name, unsigned char *sha1)\n \treturn st;\n }\n \n+/* parse @something syntax, when 'something' is not {.*} */\n+static int interpret_empty_at(const char *name, int namelen, int len, struct strbuf *buf)\n+{\n+\tif (len || name[1] == '{')\n+\t\treturn -1;\n+\n+\tstrbuf_reset(buf);\n+\tstrbuf_add(buf, \"HEAD\", 4);\n+\treturn 1;\n+}\n+\n static int reinterpret(const char *name, int namelen, int len, struct strbuf *buf)\n {\n \t/* we have extra data, which might need further processing */\n@@ -1025,9 +1036,15 @@ int interpret_branch_name(const char *name, struct strbuf *buf)\n \tcp = strchr(name, '@');\n \tif (!cp)\n \t\treturn -1;\n+\n+\tlen = interpret_empty_at(name, namelen, cp - name, buf);\n+\tif (len > 0)\n+\t\treturn reinterpret(name, namelen, len, buf);\n+\n \ttmp_len = upstream_mark(cp, namelen - (cp - name));\n \tif (!tmp_len)\n \t\treturn -1;\n+\n \tlen = cp + tmp_len - name;\n \tcp = xstrndup(name, cp - name);\n \tupstream = branch_get(*cp ? cp : NULL);\ndiff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh\nindex d5d6244..65584c0 100755\n--- a/t/t1508-at-combinations.sh\n+++ b/t/t1508-at-combinations.sh\n@@ -45,6 +45,9 @@ check \"@{u}\" upstream-two\n check \"@{u}@{1}\" upstream-one\n check \"@{-1}@{u}\" master-two\n check \"@{-1}@{u}@{1}\" master-one\n+check \"@\" new-two\n+check \"HEAD@{u}\" upstream-two\n+check \"@@{u}\" upstream-two\n nonsense \"@{u}@{-1}\"\n nonsense \"@{1}@{u}\"\n \n-- \n1.8.3.rc0.399.gc96a135\n"},{"id":"216131","messageId":"CAPig+cSQeU8BaaPm7GfCUxtsVj1Ce31ygBLdkb5WN8o4aNMAow@mail.gmail.com","threadId":"33693","inReplyTo":"1367401888-21055-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH v3] Add new @ shortcut for HEAD","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-05-01T10:12:05Z","receivedAt":"2013-05-01T10:12:05Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras\n wrote:\n> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can\n> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we\n> can't remove '{0}'?\n>\n> This patch allows '@' to be the same as 'HEAD'.\n>\n> So now we can use 'git show @~1', and all that goody goodness.\n>\n> Until now '@' was a valid name, but it conflicts with this idea, so lets\n\ns/lets/let's/ (contraction of \"let us\")\n\n> make it invalid. Probably very few people, if any, used this name.\n>\n> Signed-off-by: Felipe Contreras \n"},{"id":"216132","messageId":"CA+39Oz7gib+dpW1CNEHtD2M6JcOF1QuxpeOWLcyTxdVPGnS5+A@mail.gmail.com","threadId":"33693","inReplyTo":"CAPig+cSQeU8BaaPm7GfCUxtsVj1Ce31ygBLdkb5WN8o4aNMAow@mail.gmail.com","subject":"Re: [PATCH v3] Add new @ shortcut for HEAD","fromName":"Thomas Adam","fromEmail":"thomas@xteddy.org","sentAt":"2013-05-01T10:31:10Z","receivedAt":"2013-05-01T10:31:10Z","isPatch":true,"sender":{"key":"thomas@xteddy.org","avatar":"https://gravatar.com/avatar/e7256db4738e501e5d2e84f00bb0bd99503165729573848a03330301fc2adc4a?d=mp&s=160"},"body":"On 1 May 2013 11:12, Eric Sunshine wrote:\n> On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras\n> wrote:\n>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can\n>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we\n>> can't remove '{0}'?\n>>\n>> This patch allows '@' to be the same as 'HEAD'.\n>>\n>> So now we can use 'git show @~1', and all that goody goodness.\n>>\n>> Until now '@' was a valid name, but it conflicts with this idea, so lets\n>\n> s/lets/let's/ (contraction of \"let us\")\n\nAh, the contraction versus the first person singular. In this case\nwhere the context is concluding in decision, rather than making a\nstatement (\"Let's go to the shops\", for example) then \"lets\" is the\ncorrect word to use here.\n\n-- Thomas Adam\n"},{"id":"216145","messageId":"5181257C.2050108@xiplink.com","threadId":"33693","inReplyTo":"CA+39Oz7gib+dpW1CNEHtD2M6JcOF1QuxpeOWLcyTxdVPGnS5+A@mail.gmail.com","subject":"\"lets\" vs. \"let's\" (was: Re: [PATCH v3] Add new @ shortcut for HEAD)","fromName":"Marc Branchaud","fromEmail":"mbranchaud@xiplink.com","sentAt":"2013-05-01T14:23:56Z","receivedAt":"2013-05-01T14:23:56Z","isPatch":true,"sender":{"key":"mbranchaud@xiplink.com","avatar":null},"body":"On 13-05-01 06:31 AM, Thomas Adam wrote:\n> On 1 May 2013 11:12, Eric Sunshine wrote:\n>> On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras\n>> wrote:\n>>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can\n>>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we\n>>> can't remove '{0}'?\n>>>\n>>> This patch allows '@' to be the same as 'HEAD'.\n>>>\n>>> So now we can use 'git show @~1', and all that goody goodness.\n>>>\n>>> Until now '@' was a valid name, but it conflicts with this idea, so lets\n>>\n>> s/lets/let's/ (contraction of \"let us\")\n> \n> Ah, the contraction versus the first person singular. In this case\n> where the context is concluding in decision, rather than making a\n> statement (\"Let's go to the shops\", for example) then \"lets\" is the\n> correct word to use here.\n\nYou've lost me. I think Eric is right. If \"lets\" is a verb in this\nsentence, what is its subject?\n\nBesides, of which verb & tense is \"lets\" the first person singular? Never\nhave I \"lets\" anything in my life... :)\n\n\t\tM.\n"},{"id":"216156","messageId":"7v61z28vph.fsf@alter.siamese.dyndns.org","threadId":"33693","inReplyTo":"5181257C.2050108@xiplink.com","subject":"Re: \"lets\" vs. \"let's\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-01T17:18:50Z","receivedAt":"2013-05-01T17:18:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> On 13-05-01 06:31 AM, Thomas Adam wrote:\n>> On 1 May 2013 11:12, Eric Sunshine wrote:\n>>> On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras\n>>> wrote:\n>>>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can\n>>>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we\n>>>> can't remove '{0}'?\n>>>>\n>>>> This patch allows '@' to be the same as 'HEAD'.\n>>>>\n>>>> So now we can use 'git show @~1', and all that goody goodness.\n>>>>\n>>>> Until now '@' was a valid name, but it conflicts with this idea, so lets\n>>>\n>>> s/lets/let's/ (contraction of \"let us\")\n>> \n>> Ah, the contraction versus the first person singular. In this case\n>> where the context is concluding in decision, rather than making a\n>> statement (\"Let's go to the shops\", for example) then \"lets\" is the\n>> correct word to use here.\n>\n> You've lost me. I think Eric is right. If \"lets\" is a verb in this\n> sentence, what is its subject?\n>\n> Besides, of which verb & tense is \"lets\" the first person singular? Never\n> have I \"lets\" anything in my life... :)\n\nI'll queue with:\n\n\t... '@' was a valid name, but it conflicts with this idea,\n\tso make it invalid.\n\nThat is, just use the imperative mood to give an order to the\ncodebase to \"make it so\", which is a common style of log messages in\nthis project.\n"},{"id":"216158","messageId":"7vr4hq7fjy.fsf@alter.siamese.dyndns.org","threadId":"33693","inReplyTo":"1367401888-21055-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH v3] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-01T17:53:05Z","receivedAt":"2013-05-01T17:53:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can\n> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we\n> can't remove '{0}'?\n>\n> This patch allows '@' to be the same as 'HEAD'.\n\nWhile the above reasoning is cute, it is misleading.\n\nIf you start from HEAD@{1}~0^0, we can remove '^0', we can remove\n'~0', but you cannot remove HEAD from the remaining \"HEAD@{1}\"\nwithout changing what it means. @{1} is where the current branch\nwas, while HEAD@{1} is where you were---they are different when you\nhave just did \"git checkout anotherbranch\". HEAD@{1} is the tip of\nyour previous branch, @{1} is where anotherbranch was before its tip\nbecame the commit you have checked out.\n\nYou have to be specially talking about \"HEAD@{0}\" as a whole for\nthat reasoning to hold; it does not work for HEAD@{$n} for an\narbitrary value of $n.\n\nSo I'd suggest toning it down, perhaps something like this:\n\n\tEven though we often can do without having to type \"HEAD\",\n\te.g. \"git log origin..\" substitutes missing RHS with \"HEAD\",\n\tsometimes we still do need to type \"HEAD\" (thats six f*cking\n\tkeystrokes \"Caps Lock\", \"H\", \"E\", \"A\", \"D\" and finally \"Caps\n\tLock\").\n\n That is four keystrokes too many to name an often needed\n\treference. Make \"@\" usable as its synonym.\n\n>\n> So now we can use 'git show @~1', and all that goody goodness.\n>\n> Until now '@' was a valid name, but it conflicts with this idea, so lets\n> make it invalid. Probably very few people, if any, used this name.\n>\n> Signed-off-by: Felipe Contreras \n> ---\n> diff --git a/sha1_name.c b/sha1_name.c\n> index 76e3219..3b06e5e 100644\n> --- a/sha1_name.c\n> +++ b/sha1_name.c\n> @@ -965,6 +965,17 @@ int get_sha1_mb(const char *name, unsigned char *sha1)\n> \treturn st;\n> }\n> \n> +/* parse @something syntax, when 'something' is not {.*} */\n> +static int interpret_empty_at(const char *name, int namelen, int len, struct strbuf *buf)\n> +{\n> +\tif (len || name[1] == '{')\n> +\t\treturn -1;\n\nThis function is to handle a string that begins with '@', so by\ndefinition len is zero when anything useful is done by it. So...\n\n> +\tstrbuf_reset(buf);\n> +\tstrbuf_add(buf, \"HEAD\", 4);\n> +\treturn 1;\n> +}\n> +\n> static int reinterpret(const char *name, int namelen, int len, struct strbuf *buf)\n> {\n> \t/* we have extra data, which might need further processing */\n> @@ -1025,9 +1036,15 @@ int interpret_branch_name(const char *name, struct strbuf *buf)\n> \tcp = strchr(name, '@');\n> \tif (!cp)\n> \t\treturn -1;\n> +\n> +\tlen = interpret_empty_at(name, namelen, cp - name, buf);\n\n... it is suboptimal (from readability point of view) to have the\ncaller unconditionally call interpret_empty_at() when the function\nclearly is marked to handle something that _begins_ with '@'.\n\nI would suggest something like\n\n\tif (cp == name)\n \tlen = interpret_empty_at(name, namelen, buf);\n\nwhich people may find much easier to follow.\n\nFor that matter, it may make even more sense to just remove the\n\"empty-at\" function and inline its body here:\n\n\tif (cp == name && name[1] != '{') {\n\t\tstrbuf_reset(buf);\n strbuf_add(buf, \"HEAD\", 4);\n len = 1;\n } else {\n \tlen = -1;\n\t}\n\n> +\tif (len > 0)\n> +\t\treturn reinterpret(name, namelen, len, buf);\n> +\n> \ttmp_len = upstream_mark(cp, namelen - (cp - name));\n> \tif (!tmp_len)\n> \t\treturn -1;\n> +\n> \tlen = cp + tmp_len - name;\n> \tcp = xstrndup(name, cp - name);\n> \tupstream = branch_get(*cp ? cp : NULL);\n> diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh\n> index d5d6244..65584c0 100755\n> --- a/t/t1508-at-combinations.sh\n> +++ b/t/t1508-at-combinations.sh\n> @@ -45,6 +45,9 @@ check \"@{u}\" upstream-two\n> check \"@{u}@{1}\" upstream-one\n> check \"@{-1}@{u}\" master-two\n> check \"@{-1}@{u}@{1}\" master-one\n> +check \"@\" new-two\n> +check \"HEAD@{u}\" upstream-two\n> +check \"@@{u}\" upstream-two\n> nonsense \"@{u}@{-1}\"\n> nonsense \"@{1}@{u}\"\n"},{"id":"216166","messageId":"CAMP44s16X8c_5GgW=ZcA9wrd=oHAiVDZFWxqiGmysaUJckZ5wQ@mail.gmail.com","threadId":"33693","inReplyTo":"7vr4hq7fjy.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-01T18:33:43Z","receivedAt":"2013-05-01T18:33:43Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can\n>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we\n>> can't remove '{0}'?\n>>\n>> This patch allows '@' to be the same as 'HEAD'.\n>\n> While the above reasoning is cute, it is misleading.\n>\n> If you start from HEAD@{1}~0^0, we can remove '^0', we can remove\n> '~0', but you cannot remove HEAD from the remaining \"HEAD@{1}\"\n> without changing what it means. @{1} is where the current branch\n> was, while HEAD@{1} is where you were---they are different when you\n> have just did \"git checkout anotherbranch\". HEAD@{1} is the tip of\n> your previous branch, @{1} is where anotherbranch was before its tip\n> became the commit you have checked out.\n\nReplace @{1} with @{u} and it holds.\n\n> You have to be specially talking about \"HEAD@{0}\" as a whole for\n> that reasoning to hold; it does not work for HEAD@{$n} for an\n> arbitrary value of $n.\n>\n> So I'd suggest toning it down, perhaps something like this:\n>\n> Even though we often can do without having to type \"HEAD\",\n> e.g. \"git log origin..\" substitutes missing RHS with \"HEAD\",\n> sometimes we still do need to type \"HEAD\" (thats six f*cking\n> keystrokes \"Caps Lock\", \"H\", \"E\", \"A\", \"D\" and finally \"Caps\n> Lock\").\n\nI don't know what RHS means, and I don't use caps lock :)\n\n> That is four keystrokes too many to name an often needed\n> reference. Make \"@\" usable as its synonym.\n\nYeah, that's nice, but doesn't explain why \"@\", and why not something else.\n\n>> So now we can use 'git show @~1', and all that goody goodness.\n>>\n>> Until now '@' was a valid name, but it conflicts with this idea, so lets\n>> make it invalid. Probably very few people, if any, used this name.\n>>\n>> Signed-off-by: Felipe Contreras \n>> ---\n>> diff --git a/sha1_name.c b/sha1_name.c\n>> index 76e3219..3b06e5e 100644\n>> --- a/sha1_name.c\n>> +++ b/sha1_name.c\n>> @@ -965,6 +965,17 @@ int get_sha1_mb(const char *name, unsigned char *sha1)\n>> return st;\n>> }\n>>\n>> +/* parse @something syntax, when 'something' is not {.*} */\n>> +static int interpret_empty_at(const char *name, int namelen, int len, struct strbuf *buf)\n>> +{\n>> + if (len || name[1] == '{')\n>> + return -1;\n>\n> This function is to handle a string that begins with '@', so by\n> definition len is zero when anything useful is done by it. So...\n>\n>> + strbuf_reset(buf);\n>> + strbuf_add(buf, \"HEAD\", 4);\n>> + return 1;\n>> +}\n>> +\n>> static int reinterpret(const char *name, int namelen, int len, struct strbuf *buf)\n>> {\n>> /* we have extra data, which might need further processing */\n>> @@ -1025,9 +1036,15 @@ int interpret_branch_name(const char *name, struct strbuf *buf)\n>> cp = strchr(name, '@');\n>> if (!cp)\n>> return -1;\n>> +\n>> + len = interpret_empty_at(name, namelen, cp - name, buf);\n>\n> ... it is suboptimal (from readability point of view) to have the\n> caller unconditionally call interpret_empty_at() when the function\n> clearly is marked to handle something that _begins_ with '@'.\n>\n> I would suggest something like\n>\n> if (cp == name)\n> len = interpret_empty_at(name, namelen, buf);\n>\n> which people may find much easier to follow.\n\nWhy are we then doing:\n\n int len = interpret_nth_prior_checkout(name, buf);\n\nThis function also needs the string to begin with '@', but we don't\ncheck that, we leave that to the function to let us know if it did\ninterpret it, or not.\n\n> For that matter, it may make even more sense to just remove the\n> \"empty-at\" function and inline its body here:\n>\n> if (cp == name && name[1] != '{') {\n> strbuf_reset(buf);\n> strbuf_add(buf, \"HEAD\", 4);\n> len = 1;\n> } else {\n> len = -1;\n> }\n>\n>> + if (len > 0)\n>> + return reinterpret(name, namelen, len, buf);\n>> +\n\nIf you are going to do that, there's no need to check len separately.\n\n\tif (cp == name && name[1] != '{') {\n\t\tstrbuf_reset(buf);\n\t\tstrbuf_add(buf, \"HEAD\", 4);\n\t\treturn reinterpret(name, namelen, 1, buf);\n\t}\n\nBut I think it's less readable.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"216206","messageId":"7vsj264am4.fsf@alter.siamese.dyndns.org","threadId":"33693","inReplyTo":"CAMP44s16X8c_5GgW=ZcA9wrd=oHAiVDZFWxqiGmysaUJckZ5wQ@mail.gmail.com","subject":"Re: [PATCH v3] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-01T22:08:03Z","receivedAt":"2013-05-01T22:08:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>>\n>>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can\n>>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we\n>>> can't remove '{0}'?\n>>>\n>>> This patch allows '@' to be the same as 'HEAD'.\n>>\n>> While the above reasoning is cute, it is misleading.\n>>\n>> If you start from HEAD@{1}~0^0, we can remove '^0', we can remove\n>> '~0', but you cannot remove HEAD from the remaining \"HEAD@{1}\"\n>> without changing what it means. @{1} is where the current branch\n>> was, while HEAD@{1} is where you were---they are different when you\n>> have just did \"git checkout anotherbranch\". HEAD@{1} is the tip of\n>> your previous branch, @{1} is where anotherbranch was before its tip\n>> became the commit you have checked out.\n>\n> Replace @{1} with @{u} and it holds.\n\nYes and no. Starting from HEAD@{u}~0^0, we can remove ^0 and ~0,\nand you remove HEAD from the remaining \"HEAD@{u}\" to get @{u} and\nall of them still mean the same thing. It is the other branch your\ncurrent branch is integrating with.\n\nBut that decomposition does not get you to HEAD which is the final\ndestination you want to reach. As soon as you drop the remaining\n{u}, it suddenly changes the meaning and start referring to the\ncurrent branch.\n\n>> So I'd suggest toning it down, perhaps something like this:\n>>\n>> Even though we often can do without having to type \"HEAD\",\n>> e.g. \"git log origin..\" substitutes missing RHS with \"HEAD\",\n>> sometimes we still do need to type \"HEAD\" (thats six f*cking\n>> keystrokes \"Caps Lock\", \"H\", \"E\", \"A\", \"D\" and finally \"Caps\n>> Lock\").\n>\n> I don't know what RHS means, and I don't use caps lock :)\n\n\"right hand side\"? You can say \"Hold down Shift\", H, E, A, D and\n\"Release Shift\" ;-).\n\n>> That is four keystrokes too many to name an often needed\n>> reference. Make \"@\" usable as its synonym.\n>\n> Yeah, that's nice, but doesn't explain why \"@\", and why not something else.\n\nThe thing is, HEAD@{0}~0^0 nor HEAD@{u}~0^0 is not a valid\nexplanation why it is \"@\", either.\n\nBut that does _not_ mean \"@\" is a good choice. Nor the explanation\nhas to be based on the \"starting from this and strip\" progression.\n\n\"@\" is already special and is familiar to users when specifying a\nref, and that is a good enough reason (you can of course say that in\nthe log message).\n"},{"id":"216212","messageId":"CAMP44s0OysW1Rnc+Dk1R697zhtV+ubCMfDa+aWizOaHEcLbsJA@mail.gmail.com","threadId":"33693","inReplyTo":"7vsj264am4.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-01T22:35:03Z","receivedAt":"2013-05-01T22:35:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 1, 2013 at 5:08 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> On Wed, May 1, 2013 at 12:53 PM, Junio C Hamano wrote:\n>>> Felipe Contreras writes:\n>>>\n>>>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can\n>>>> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we\n>>>> can't remove '{0}'?\n>>>>\n>>>> This patch allows '@' to be the same as 'HEAD'.\n>>>\n>>> While the above reasoning is cute, it is misleading.\n>>>\n>>> If you start from HEAD@{1}~0^0, we can remove '^0', we can remove\n>>> '~0', but you cannot remove HEAD from the remaining \"HEAD@{1}\"\n>>> without changing what it means. @{1} is where the current branch\n>>> was, while HEAD@{1} is where you were---they are different when you\n>>> have just did \"git checkout anotherbranch\". HEAD@{1} is the tip of\n>>> your previous branch, @{1} is where anotherbranch was before its tip\n>>> became the commit you have checked out.\n>>\n>> Replace @{1} with @{u} and it holds.\n>\n> Yes and no. Starting from HEAD@{u}~0^0, we can remove ^0 and ~0,\n> and you remove HEAD from the remaining \"HEAD@{u}\" to get @{u} and\n> all of them still mean the same thing. It is the other branch your\n> current branch is integrating with.\n>\n> But that decomposition does not get you to HEAD which is the final\n> destination you want to reach. As soon as you drop the remaining\n> {u}, it suddenly changes the meaning and start referring to the\n> current branch.\n\nYeah, @something has different meaning depending on what that\n'something' is. We could add @{this-branch} to mean this is basically\na no-op, and then we can do the HEAD@{this-branch}~0^0 reduction\nstraight-forwardly, but I think it's overkill to add a new idiom only\nto prove a point.\n\nAt the end of the day the important thing is that @ is the same as\n@something, except without the 'something' in there. That's why the\nshortcut is @, and not '.', or '+', or '&', or any number of other\nsingle characters we could have chosen.\n\n>>> So I'd suggest toning it down, perhaps something like this:\n>>>\n>>> Even though we often can do without having to type \"HEAD\",\n>>> e.g. \"git log origin..\" substitutes missing RHS with \"HEAD\",\n>>> sometimes we still do need to type \"HEAD\" (thats six f*cking\n>>> keystrokes \"Caps Lock\", \"H\", \"E\", \"A\", \"D\" and finally \"Caps\n>>> Lock\").\n>>\n>> I don't know what RHS means, and I don't use caps lock :)\n>\n> \"right hand side\"? You can say \"Hold down Shift\", H, E, A, D and\n> \"Release Shift\" ;-).\n\nYeah, but the point is that different people have different ways of\ndoing it. Even if it was 'head' it would be a burden.\n\n>>> That is four keystrokes too many to name an often needed\n>>> reference. Make \"@\" usable as its synonym.\n>>\n>> Yeah, that's nice, but doesn't explain why \"@\", and why not something else.\n>\n> The thing is, HEAD@{0}~0^0 nor HEAD@{u}~0^0 is not a valid\n> explanation why it is \"@\", either.\n\nLet's pick '+' then. Or something else.\n\n> But that does _not_ mean \"@\" is a good choice. Nor the explanation\n> has to be based on the \"starting from this and strip\" progression.\n>\n> \"@\" is already special and is familiar to users when specifying a\n> ref, and that is a good enough reason (you can of course say that in\n> the log message).\n\nExactly, because ref@something is used for operations on a ref. If\n'ref' is missing, it only makes sense to use HEAD (or something like\nthat), and if 'something' is missing, it only makes sense to make it a\nno-op, but since we don't want to forbid refs with names like\n'master@'. That's the reason why '@' makes sense, and not any other\ncharacter.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"216215","messageId":"7v8v3y48cl.fsf@alter.siamese.dyndns.org","threadId":"33693","inReplyTo":"7vsj264am4.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-01T22:56:58Z","receivedAt":"2013-05-01T22:56:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> The thing is, HEAD@{0}~0^0 nor HEAD@{u}~0^0 is not a valid\n> explanation why it is \"@\", either.\n>\n> But that does _not_ mean \"@\" is a good choice. Nor the explanation\n\nArrgh. It does not mean \" '@' is a BAD choice \". '@' _is_ good.\nBut the point is that the explanation does not have to be a\ntechnically incorrect \"strip this, strip that\".\n"},{"id":"216216","messageId":"7v4nem488y.fsf@alter.siamese.dyndns.org","threadId":"33693","inReplyTo":"CAMP44s0OysW1Rnc+Dk1R697zhtV+ubCMfDa+aWizOaHEcLbsJA@mail.gmail.com","subject":"Re: [PATCH v3] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-01T22:59:09Z","receivedAt":"2013-05-01T22:59:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Exactly, because ref@something is used for operations on a ref. If\n> 'ref' is missing, it only makes sense to use HEAD (or something like\n> that), and if 'something' is missing, it only makes sense to make it a\n> no-op, but since we don't want to forbid refs with names like\n> 'master@'. That's the reason why '@' makes sense, and not any other\n> character.\n\nYes. My typo made it look as if I meant to say '@' was a bad\nchoice, but we are in agreement that '@' is better than any other\nrandom choice of single punctuation letter.\n\nIt is just the \"strip this, strip that\" explanation, which is not\ntechnically correct, does _not_ have to be our justification for\npicking '@' as a short-hand for HEAD.\n"},{"id":"216219","messageId":"CAMP44s0TtwBL=0MxU2C8QUkgA61KauPTcctH9TzQ_DdTaxh0eg@mail.gmail.com","threadId":"33693","inReplyTo":"7v4nem488y.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-01T23:14:41Z","receivedAt":"2013-05-01T23:14:41Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 1, 2013 at 5:59 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> Exactly, because ref@something is used for operations on a ref. If\n>> 'ref' is missing, it only makes sense to use HEAD (or something like\n>> that), and if 'something' is missing, it only makes sense to make it a\n>> no-op, but since we don't want to forbid refs with names like\n>> 'master@'. That's the reason why '@' makes sense, and not any other\n>> character.\n>\n> Yes. My typo made it look as if I meant to say '@' was a bad\n> choice, but we are in agreement that '@' is better than any other\n> random choice of single punctuation letter.\n\nYeah, we agree.\n\n> It is just the \"strip this, strip that\" explanation, which is not\n> technically correct, does _not_ have to be our justification for\n> picking '@' as a short-hand for HEAD.\n\nThe point is that it follows from @something -> @.\n\n-- \nFelipe Contreras\n"},{"id":"216227","messageId":"CAMP44s0zbb7GO2oFZ5LhSu3Xu_SMZcit5Yzqk+E=4XoO9Ju5Bw@mail.gmail.com","threadId":"33693","inReplyTo":"CAMP44s0TtwBL=0MxU2C8QUkgA61KauPTcctH9TzQ_DdTaxh0eg@mail.gmail.com","subject":"Re: [PATCH v3] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-02T02:33:21Z","receivedAt":"2013-05-02T02:33:21Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 1, 2013 at 6:14 PM, Felipe Contreras\n wrote:\n> On Wed, May 1, 2013 at 5:59 PM, Junio C Hamano wrote:\n\n>> It is just the \"strip this, strip that\" explanation, which is not\n>> technically correct, does _not_ have to be our justification for\n>> picking '@' as a short-hand for HEAD.\n>\n> The point is that it follows from @something -> @.\n\nSo my proposal is:\n\n---\nTyping 'HEAD' is tedious, especially when we can use '@' instead.\n\nThe reason for choosing '@' is that it follows naturally from the\nref@op syntax (e.g. HEAD@{u}), except we have no ref, and no\noperation, and when we don't have those, it makes sens to assume\n'HEAD'.\n\nAfter this patch, we can use 'git show @~1', and all that goody goodness.\n\nUntil now '@' was a valid ref name, but it conflicts with this idea, so lets\nmake it invalid. Probably very few people, if any, used this symbolic ref.\n---\n\n-- \nFelipe Contreras\n"},{"id":"216500","messageId":"7vk3nctb8z.fsf@alter.siamese.dyndns.org","threadId":"33693","inReplyTo":"CAMP44s0zbb7GO2oFZ5LhSu3Xu_SMZcit5Yzqk+E=4XoO9Ju5Bw@mail.gmail.com","subject":"Re: [PATCH v3] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-06T14:48:44Z","receivedAt":"2013-05-06T14:48:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Wed, May 1, 2013 at 6:14 PM, Felipe Contreras\n> wrote:\n>> On Wed, May 1, 2013 at 5:59 PM, Junio C Hamano wrote:\n>\n>>> It is just the \"strip this, strip that\" explanation, which is not\n>>> technically correct, does _not_ have to be our justification for\n>>> picking '@' as a short-hand for HEAD.\n>>\n>> The point is that it follows from @something -> @.\n>\n> So my proposal is:\n>\n> ---\n> Typing 'HEAD' is tedious, especially when we can use '@' instead.\n>\n> The reason for choosing '@' is that it follows naturally from the\n> ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no\n> operation, and when we don't have those, it makes sens to assume\n> 'HEAD'.\n>\n> After this patch, we can use 'git show @~1', and all that goody goodness.\n\nThat reads much better.\n"}]}