{"thread":{"id":"33673","subject":"[PATCH] Add new @ shortcut for HEAD","startedAt":"2013-04-29T19:35:06Z","lastAt":"2013-04-30T23:24:08Z","messageCount":56,"participants":["Felipe Contreras","Ramkumar Ramachandra","Junio C Hamano","Jonathan Nieder","Duy Nguyen","Michael Haggerty","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"215907","messageId":"1367264106-2351-1-git-send-email-felipe.contreras@gmail.com","threadId":"33673","inReplyTo":null,"subject":"[PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-29T19:35:06Z","receivedAt":"2013-04-29T19:35:06Z","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', but we can't remove '{0}'?\n\nThis patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n'master@'.\n\nSo we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\nuse 'git show @~1', and all that goody goodness.\n\nSigned-off-by: Felipe Contreras \n---\n\nPeople have complained about the lack of a HEAD shortcut before, and some\nproposals have been made, but I think this one is a clean trick in accordance\nwith our current syntax.\n\n Documentation/revisions.txt | 3 +++\n sha1_name.c | 8 +++++++-\n t/t1503-rev-parse-verify.sh | 9 +++++++++\n 3 files changed, 19 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/revisions.txt b/Documentation/revisions.txt\nindex d477b3f..6315ce5 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/sha1_name.c b/sha1_name.c\nindex 3820f28..d7c3d6f 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -437,11 +437,15 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n \tstatic const char *warn_msg = \"refname '%.*s' is ambiguous.\";\n \tchar *real_ref = NULL;\n \tint refs_found = 0;\n-\tint at, reflog_len;\n+\tint at, reflog_len, empty_at;\n \n \tif (len == 40 && !get_sha1_hex(str, sha1))\n \t\treturn 0;\n \n+\tempty_at = len && str[len-1] == '@';\n+\tif (empty_at)\n+\t\tlen = len-1;\n+\n \t/* basic@{time or number or -number} format to query ref-log */\n \treflog_len = at = 0;\n \tif (len && str[len-1] == '}') {\n@@ -475,6 +479,8 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n \t\trefs_found = dwim_ref(\"HEAD\", 4, sha1, &real_ref);\n \t} else if (reflog_len)\n \t\trefs_found = dwim_log(str, len, sha1, &real_ref);\n+\telse if (!len && empty_at)\n+\t\trefs_found = dwim_ref(\"HEAD\", 4, sha1, &real_ref);\n \telse\n \t\trefs_found = dwim_ref(str, len, sha1, &real_ref);\n \ndiff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh\nindex 813cc1b..426c63f 100755\n--- a/t/t1503-rev-parse-verify.sh\n+++ b/t/t1503-rev-parse-verify.sh\n@@ -115,4 +115,13 @@ test_expect_success 'master@{n} for various n' '\n \ttest_must_fail git rev-parse --verify master@{$Np1}\n '\n \n+test_expect_success 'empty @' '\n+\trev_hash=$(git rev-parse --verify @) &&\n+\ttest \"$rev_hash\" = \"$HASH4\" &&\n+\trev_hash=$(git rev-parse --verify HEAD@) &&\n+\ttest \"$rev_hash\" = \"$HASH4\" &&\n+\trev_hash=$(git rev-parse --verify master@) &&\n+\ttest \"$rev_hash\" = \"$HASH4\"\n+'\n+\n test_done\n-- \n1.8.2.1.1031.g2ee5873\n"},{"id":"215909","messageId":"CALkWK0=Qo2aPz3+DDiHV77Z=+jeqwanAOMZHFLLMzm5BS_n0uw@mail.gmail.com","threadId":"33673","inReplyTo":"1367264106-2351-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-29T19:43:54Z","receivedAt":"2013-04-29T19:43:54Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n> use 'git show @~1', and all that goody goodness.\n\nGood one. This is what I didn't think of.\n\nThe implementation looks beautiful, and I have nothing more to say\nabout the patch.\n"},{"id":"215911","messageId":"7va9ohhzsi.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"1367264106-2351-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-29T20:01:17Z","receivedAt":"2013-04-29T20:01:17Z","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', but we can't remove '{0}'?\n>\n> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n> 'master@'.\n>\n> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n> use 'git show @~1', and all that goody goodness.\n>\n> Signed-off-by: Felipe Contreras \n> ---\n>\n> People have complained about the lack of a HEAD shortcut before, and some\n> proposals have been made, but I think this one is a clean trick in accordance\n> with our current syntax.\n\nTechnically the notation would be only valid if you have a reflog on\nit, but if we must have such a notation, I think this may end up to\nbe the least bad one. I haven't thought things through, though, so\nwon't stand behind it myself (i.e. when there are corner-case holes\nfound later, I won't defend the notation myself), at least not yet.\n"},{"id":"215912","messageId":"7v61z5hzqg.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"1367264106-2351-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-29T20:02:31Z","receivedAt":"2013-04-29T20:02:31Z","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', but we can't remove '{0}'?\n\nAnother technical issue, even if you have reflogs.\n\nHEAD@{0} and @{0} are referring to two different reflogs, and means\ndifferent things, even though they may refer to the same commit.\n\nBut the comment in my previous message still stands.\n"},{"id":"215913","messageId":"CAMP44s3ghzcfTthEEYZgr7ydJFUeA5xKyAxgR1JUYVtWG7f=qg@mail.gmail.com","threadId":"33673","inReplyTo":"7va9ohhzsi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-29T20:14:12Z","receivedAt":"2013-04-29T20:14:12Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 29, 2013 at 3:01 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', but we can't remove '{0}'?\n>>\n>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>> 'master@'.\n>>\n>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n>> use 'git show @~1', and all that goody goodness.\n>>\n>> Signed-off-by: Felipe Contreras \n>> ---\n>>\n>> People have complained about the lack of a HEAD shortcut before, and some\n>> proposals have been made, but I think this one is a clean trick in accordance\n>> with our current syntax.\n>\n> Technically the notation would be only valid if you have a reflog on\n> it, but if we must have such a notation, I think this may end up to\n> be the least bad one. I haven't thought things through, though, so\n> won't stand behind it myself (i.e. when there are corner-case holes\n> found later, I won't defend the notation myself), at least not yet.\n\nBut @ is not used just for reflogs, there's @{now}, @{-1}, @{upstream}.\n\n-- \nFelipe Contreras\n"},{"id":"215914","messageId":"CAMP44s0rT1097=481aSH=Gy465zb2Bd_xLv=Xvte-GHcamWLyA@mail.gmail.com","threadId":"33673","inReplyTo":"7v61z5hzqg.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-29T20:23:52Z","receivedAt":"2013-04-29T20:23:52Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 29, 2013 at 3:02 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', but we can't remove '{0}'?\n>\n> Another technical issue, even if you have reflogs.\n>\n> HEAD@{0} and @{0} are referring to two different reflogs, and means\n> different things, even though they may refer to the same commit.\n\nHow? AFAICS the code substitutes @{0} with HEAD@{0}.\n\nPlus 'git show HEAD@{1}', 'git show current-branch@{1}', and 'git show\n@{1}' all show the same thing, even though 'git relog HEAD' shows a\ndifferent commit for HEAD@{1}.\n\n-- \nFelipe Contreras\n"},{"id":"215915","messageId":"7v1u9thyq9.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"CAMP44s3ghzcfTthEEYZgr7ydJFUeA5xKyAxgR1JUYVtWG7f=qg@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-29T20:24:14Z","receivedAt":"2013-04-29T20:24:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> But @ is not used just for reflogs, there's @{now}, @{-1}, @{upstream}.\n\nTrue. @{now} is a reflog, @{-1} is also but @{u} is not. It is a\nkitchen sink and you shouldn't have to have reflog on a branch in\norder to use @{upstream} (I didn't check---I wouldn't be surprised\nif the code for @{u} is buggy and barfed).\n"},{"id":"215916","messageId":"CAMP44s044amTqdshNAm=EaT1UgEtKU6yLWAxsk3GwCcX+GQKxQ@mail.gmail.com","threadId":"33673","inReplyTo":"7v1u9thyq9.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-29T20:38:40Z","receivedAt":"2013-04-29T20:38:40Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 29, 2013 at 3:24 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> But @ is not used just for reflogs, there's @{now}, @{-1}, @{upstream}.\n>\n> True. @{now} is a reflog, @{-1} is also but @{u} is not. It is a\n> kitchen sink and you shouldn't have to have reflog on a branch in\n> order to use @{upstream} (I didn't check---I wouldn't be surprised\n> if the code for @{u} is buggy and barfed).\n\nIt shouldn't matter if @{u} is buggy or not (which I doubt), @ is\nbasically @{nothing}, or @{same-commit}, whether a reflog is present\nor not doesn't really matter. HEAD@ -> HEAD, master@ -> master, and so\non.\n\n-- \nFelipe Contreras\n"},{"id":"215917","messageId":"7vtxmpgig3.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"CAMP44s044amTqdshNAm=EaT1UgEtKU6yLWAxsk3GwCcX+GQKxQ@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-29T21:01:16Z","receivedAt":"2013-04-29T21:01:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> It shouldn't matter if @{u} is buggy or not (which I doubt),\n\nOh, it wouldn't make any difference to this topic; it is just\nsomething we may want to fix if it were broken.\n"},{"id":"215923","messageId":"CAMP44s0mHxv24GtpY2KzmrKQjZo+97FNN_T7tQk_peyWmusMWA@mail.gmail.com","threadId":"33673","inReplyTo":"CAMP44s0rT1097=481aSH=Gy465zb2Bd_xLv=Xvte-GHcamWLyA@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-29T21:36:21Z","receivedAt":"2013-04-29T21:36:21Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 29, 2013 at 3:23 PM, Felipe Contreras\n wrote:\n> On Mon, Apr 29, 2013 at 3:02 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', but we can't remove '{0}'?\n>>\n>> Another technical issue, even if you have reflogs.\n>>\n>> HEAD@{0} and @{0} are referring to two different reflogs, and means\n>> different things, even though they may refer to the same commit.\n>\n> How? AFAICS the code substitutes @{0} with HEAD@{0}.\n>\n> Plus 'git show HEAD@{1}', 'git show current-branch@{1}', and 'git show\n> @{1}' all show the same thing, even though 'git relog HEAD' shows a\n> different commit for HEAD@{1}.\n\nNever-mind, now I see the difference, still, I don't think it's\nrelevant for this patch.\n\n-- \nFelipe Contreras\n"},{"id":"215927","messageId":"7vwqrlezcs.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"1367264106-2351-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-29T22:38:59Z","receivedAt":"2013-04-29T22:38:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh\n> index 813cc1b..426c63f 100755\n> --- a/t/t1503-rev-parse-verify.sh\n> +++ b/t/t1503-rev-parse-verify.sh\n> @@ -115,4 +115,13 @@ test_expect_success 'master@{n} for various n' '\n> \ttest_must_fail git rev-parse --verify master@{$Np1}\n> '\n> \n> +test_expect_success 'empty @' '\n> +\trev_hash=$(git rev-parse --verify @) &&\n> +\ttest \"$rev_hash\" = \"$HASH4\" &&\n> +\trev_hash=$(git rev-parse --verify HEAD@) &&\n> +\ttest \"$rev_hash\" = \"$HASH4\" &&\n> +\trev_hash=$(git rev-parse --verify master@) &&\n> +\ttest \"$rev_hash\" = \"$HASH4\"\n> +'\n\nDon't we have different refs that resolve to something other than\n$HASH4 at this point in the test? Otherwise we wouldn't notice a\nbreakage because we cannot tell if HEAD@ and master@ are interpreted\ncorrectly or all of these happen to yield $HASH4 because a version\nsomebody else patches to break the implementation in this patch\ndiscards any string before @ that is not followed by {stuff}.\n"},{"id":"215928","messageId":"CAMP44s2iTBW3P25RCDQCoM02K1JTs9v6-8SG91MJeUxh4b1qEQ@mail.gmail.com","threadId":"33673","inReplyTo":"7vwqrlezcs.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-29T22:49:24Z","receivedAt":"2013-04-29T22:49:24Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 29, 2013 at 5:38 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh\n>> index 813cc1b..426c63f 100755\n>> --- a/t/t1503-rev-parse-verify.sh\n>> +++ b/t/t1503-rev-parse-verify.sh\n>> @@ -115,4 +115,13 @@ test_expect_success 'master@{n} for various n' '\n>> test_must_fail git rev-parse --verify master@{$Np1}\n>> '\n>>\n>> +test_expect_success 'empty @' '\n>> + rev_hash=$(git rev-parse --verify @) &&\n>> + test \"$rev_hash\" = \"$HASH4\" &&\n>> + rev_hash=$(git rev-parse --verify HEAD@) &&\n>> + test \"$rev_hash\" = \"$HASH4\" &&\n>> + rev_hash=$(git rev-parse --verify master@) &&\n>> + test \"$rev_hash\" = \"$HASH4\"\n>> +'\n>\n> Don't we have different refs that resolve to something other than\n> $HASH4 at this point in the test?\n\nNo.\n\n> Otherwise we wouldn't notice a\n> breakage because we cannot tell if HEAD@ and master@ are interpreted\n> correctly or all of these happen to yield $HASH4 because a version\n> somebody else patches to break the implementation in this patch\n> discards any string before @ that is not followed by {stuff}.\n\n rev_hash=$(git rev-parse --verify HEAD@) &&\n test \"$rev_hash\" = \"$HASH4\" &&\n rev_hash=$(git rev-parse --verify master@) &&\n- test \"$rev_hash\" = \"$HASH4\"\n+ test \"$rev_hash\" = \"$HASH4\" &&\n+ test_must_fail git rev-parse --verify foo@\n\n-- \nFelipe Contreras\n"},{"id":"215929","messageId":"7vsj29eysv.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"CAMP44s0mHxv24GtpY2KzmrKQjZo+97FNN_T7tQk_peyWmusMWA@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-29T22:50:56Z","receivedAt":"2013-04-29T22:50:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Never-mind, now I see the difference, still, I don't think it's\n> relevant for this patch.\n\nI don't either. With the precedence of @{u}, @ does not need to have\nanything to do with a reflog. It is just a random letter that casts\na magic spell.\n"},{"id":"215931","messageId":"7vobcxey3g.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"CAMP44s2iTBW3P25RCDQCoM02K1JTs9v6-8SG91MJeUxh4b1qEQ@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-29T23:06:11Z","receivedAt":"2013-04-29T23:06:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The following message is a courtesy copy of an article\nthat has been posted to gmane.comp.version-control.git as well.\n\nFelipe Contreras writes:\n\n> On Mon, Apr 29, 2013 at 5:38 PM, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>>\n>>> diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh\n>>> index 813cc1b..426c63f 100755\n>>> --- a/t/t1503-rev-parse-verify.sh\n>>> +++ b/t/t1503-rev-parse-verify.sh\n>>> @@ -115,4 +115,13 @@ test_expect_success 'master@{n} for various n' '\n>>> test_must_fail git rev-parse --verify master@{$Np1}\n>>> '\n>>>\n>>> +test_expect_success 'empty @' '\n>>> + rev_hash=$(git rev-parse --verify @) &&\n>>> + test \"$rev_hash\" = \"$HASH4\" &&\n>>> + rev_hash=$(git rev-parse --verify HEAD@) &&\n>>> + test \"$rev_hash\" = \"$HASH4\" &&\n>>> + rev_hash=$(git rev-parse --verify master@) &&\n>>> + test \"$rev_hash\" = \"$HASH4\"\n>>> +'\n>>\n>> Don't we have different refs that resolve to something other than\n>> $HASH4 at this point in the test?\n>\n> No.\n\nOf course we're free to make some as needed; perhaps like this?\n\n t/t1503-rev-parse-verify.sh | 9 +++++++--\n 1 file changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh\nindex 426c63f..f8f3b34 100755\n--- a/t/t1503-rev-parse-verify.sh\n+++ b/t/t1503-rev-parse-verify.sh\n@@ -115,13 +115,18 @@ test_expect_success 'master@{n} for various n' '\n \ttest_must_fail git rev-parse --verify master@{$Np1}\n '\n \n-test_expect_success 'empty @' '\n+test_expect_success 'empty @ and ref@ without trailing {stuff}' '\n+\ttest_when_finished \"git branch -d twoago\" &&\n+\tgit branch twoago HEAD~2 &&\n \trev_hash=$(git rev-parse --verify @) &&\n \ttest \"$rev_hash\" = \"$HASH4\" &&\n \trev_hash=$(git rev-parse --verify HEAD@) &&\n \ttest \"$rev_hash\" = \"$HASH4\" &&\n \trev_hash=$(git rev-parse --verify master@) &&\n-\ttest \"$rev_hash\" = \"$HASH4\"\n+\ttest \"$rev_hash\" = \"$HASH4\" &&\n+\trev_hash=$(git rev-parse --verify twoago@) &&\n+\ttest \"$rev_hash\" = \"$HASH2\" &&\n+\ttest_must_fail git rev-parse --verify nosuch@\n '\n \n test_done\n"},{"id":"215932","messageId":"CAMP44s3fkrfZw-mcYKEfYy1SkGa1vvkMp14VRbwUUKcP8J-rKA@mail.gmail.com","threadId":"33673","inReplyTo":"7vobcxey3g.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-29T23:10:13Z","receivedAt":"2013-04-29T23:10:13Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 29, 2013 at 6:06 PM, Junio C Hamano wrote:\n\n> --- a/t/t1503-rev-parse-verify.sh\n> +++ b/t/t1503-rev-parse-verify.sh\n> @@ -115,13 +115,18 @@ test_expect_success 'master@{n} for various n' '\n> test_must_fail git rev-parse --verify master@{$Np1}\n> '\n>\n> -test_expect_success 'empty @' '\n> +test_expect_success 'empty @ and ref@ without trailing {stuff}' '\n> + test_when_finished \"git branch -d twoago\" &&\n> + git branch twoago HEAD~2 &&\n> rev_hash=$(git rev-parse --verify @) &&\n> test \"$rev_hash\" = \"$HASH4\" &&\n> rev_hash=$(git rev-parse --verify HEAD@) &&\n> test \"$rev_hash\" = \"$HASH4\" &&\n> rev_hash=$(git rev-parse --verify master@) &&\n> - test \"$rev_hash\" = \"$HASH4\"\n> + test \"$rev_hash\" = \"$HASH4\" &&\n> + rev_hash=$(git rev-parse --verify twoago@) &&\n> + test \"$rev_hash\" = \"$HASH2\" &&\n> + test_must_fail git rev-parse --verify nosuch@\n> '\n\nSure, but none of the tests above do that. Up to you.\n\n-- \nFelipe Contreras\n"},{"id":"215946","messageId":"20130430005304.GG24467@google.com","threadId":"33673","inReplyTo":"7vsj29eysv.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-30T00:53:04Z","receivedAt":"2013-04-30T00:53:04Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n\n>> Never-mind, now I see the difference, still, I don't think it's\n>> relevant for this patch.\n>\n> I don't either. With the precedence of @{u}, @ does not need to have\n> anything to do with a reflog. It is just a random letter that casts\n> a magic spell.\n\nI thought the convention was \"^{...} is for operators that act on\nobjects, @{...} for operators that act on refs or symrefs\".\n\nWhich works fine here.\n"},{"id":"215960","messageId":"CACsJy8D_gPpprETkAxf+eYp5DMt7uVt6nanCwthZO=vVfBT28Q@mail.gmail.com","threadId":"33673","inReplyTo":"1367264106-2351-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-04-30T05:54:39Z","receivedAt":"2013-04-30T05:54:39Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras\n wrote:\n> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n> use 'git show @~1', and all that goody goodness.\n\nI like this. I haven't spent a lot of time on thinking about\nambiguation. But I think we're safe there. '@' is not overloaded much\nlike ':', '^' or '~'.\n\n> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n> 'master@'.\n\nI'm a bit reluctant to this. It looks like incomplete syntax to me as\n'@' has always been followed by '{'. Can we have the lone '@' candy\nbut reject master@ and HEAD@? There's no actual gain in writing\nmaster@ vs master@{0}.\n\n> +'@'::\n> + '@' alone is a shortcut for 'HEAD'\n> +\n\nAnd this does not explain about HEAD@ or master@. But because I prefer\nthe candy part only. This documentation part looks good :)\n--\nDuy\n"},{"id":"215964","messageId":"CACsJy8Af5Z6DzsAchu2MpMeanTEJiF-DwhdPMGE9n6QKf2K6Eg@mail.gmail.com","threadId":"33673","inReplyTo":"1367264106-2351-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-04-30T06:07:25Z","receivedAt":"2013-04-30T06:07:25Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Apr 30, 2013 at 2:35 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', but we can't remove '{0}'?\n>\n> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n> 'master@'.\n>\n> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n> use 'git show @~1', and all that goody goodness.\n\nThis patch also allows funny things like @{-1}@ (wanted to try the\ncute syntax @{u}@ but too lazy to setup upstream)\n\n$ ./git rev-parse @{-1}\n7e6a0cc47da79dd22c0338aee8750fda92ced5d9\n$ ./git rev-parse @{-1}@\n7e6a0cc47da79dd22c0338aee8750fda92ced5d9\n$ ./git rev-parse @{-1}@{0}\n@{-1}@{0}\nfatal: ambiguous argument '@{-1}@{0}': unknown revision or path not in\nthe working tree.\nUse '--' to separate paths from revisions, like this:\n'git [...] -- [...]'\n--\nDuy\n"},{"id":"215965","messageId":"CAMP44s35HcjZ0sMjbOxHZt96v8S8eEFF+Y9JF_K9FKnFe-S9Xg@mail.gmail.com","threadId":"33673","inReplyTo":"CACsJy8D_gPpprETkAxf+eYp5DMt7uVt6nanCwthZO=vVfBT28Q@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T06:10:06Z","receivedAt":"2013-04-30T06:10:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen wrote:\n> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras\n> wrote:\n>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n>> use 'git show @~1', and all that goody goodness.\n>\n> I like this. I haven't spent a lot of time on thinking about\n> ambiguation. But I think we're safe there. '@' is not overloaded much\n> like ':', '^' or '~'.\n>\n>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>> 'master@'.\n>\n> I'm a bit reluctant to this. It looks like incomplete syntax to me as\n> '@' has always been followed by '{'. Can we have the lone '@' candy\n> but reject master@ and HEAD@? There's no actual gain in writing\n> master@ vs master@{0}.\n\nThat's what I tried first, but it just didn't feel elegant to have one\ncheck for this case only. foo@ does follow naturally, and it doesn't\nhurt.\n\n>> +'@'::\n>> + '@' alone is a shortcut for 'HEAD'\n>> +\n>\n> And this does not explain about HEAD@ or master@. But because I prefer\n> the candy part only. This documentation part looks good :)\n\nYeah, there's no point in documenting things that are not useful for\nthe user. The fact that HEAD@ is translated to HEAD is just an\nimplementation detail.\n\n-- \nFelipe Contreras\n"},{"id":"215966","messageId":"CAMP44s3zWLnXeBH2CsjDU=jXLAXMcMDSJgW9Qin=jKJrfO_2gQ@mail.gmail.com","threadId":"33673","inReplyTo":"CACsJy8Af5Z6DzsAchu2MpMeanTEJiF-DwhdPMGE9n6QKf2K6Eg@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T06:11:32Z","receivedAt":"2013-04-30T06:11:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 1:07 AM, Duy Nguyen wrote:\n> On Tue, Apr 30, 2013 at 2:35 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', but we can't remove '{0}'?\n>>\n>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>> 'master@'.\n>>\n>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n>> use 'git show @~1', and all that goody goodness.\n>\n> This patch also allows funny things like @{-1}@ (wanted to try the\n> cute syntax @{u}@ but too lazy to setup upstream)\n\nYeah, I thought about that, and I thought it was harmless. Specially\nconsidering that doing anything else would be less elegant code-wise.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215967","messageId":"CACsJy8BTj8Vb5dyJJXhAtQ4soUTAAshKATYB+f9X2p1n6VFHMQ@mail.gmail.com","threadId":"33673","inReplyTo":"CAMP44s35HcjZ0sMjbOxHZt96v8S8eEFF+Y9JF_K9FKnFe-S9Xg@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-04-30T06:17:34Z","receivedAt":"2013-04-30T06:17:34Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras\n wrote:\n> On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen wrote:\n>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras\n>> wrote:\n>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n>>> use 'git show @~1', and all that goody goodness.\n>>\n>> I like this. I haven't spent a lot of time on thinking about\n>> ambiguation. But I think we're safe there. '@' is not overloaded much\n>> like ':', '^' or '~'.\n>>\n>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>>> 'master@'.\n>>\n>> I'm a bit reluctant to this. It looks like incomplete syntax to me as\n>> '@' has always been followed by '{'. Can we have the lone '@' candy\n>> but reject master@ and HEAD@? There's no actual gain in writing\n>> master@ vs master@{0}.\n>\n> That's what I tried first, but it just didn't feel elegant to have one\n> check for this case only. foo@ does follow naturally, and it doesn't\n> hurt.\n>\n>>> +'@'::\n>>> + '@' alone is a shortcut for 'HEAD'\n>>> +\n>>\n>> And this does not explain about HEAD@ or master@. But because I prefer\n>> the candy part only. This documentation part looks good :)\n>\n> Yeah, there's no point in documenting things that are not useful for\n> the user. The fact that HEAD@ is translated to HEAD is just an\n> implementation detail.\n\nExactly. As it's implementation detail, it should not be exposed to\nuser as \"huh?\" moments when they type \"HEAD@\". I'm may be paranoid,\nbut if some user finds it nice (or just different) to try master@ in\nscripts, then we change implementation details and master@ no longer\nworks, people could be upset. Undefined behavior syntax should be kept\nto minimum. And to answer your other mail regarding the harmlessness\nof @{-1}@, I'd rather pay some extra code than leave some loose ends\nlike that.\n--\nDuy\n"},{"id":"215968","messageId":"CAMP44s2+jqj4PCMG6vsA5keymoXanpW+Lhf8+yjx7S0oGWwdiQ@mail.gmail.com","threadId":"33673","inReplyTo":"CACsJy8BTj8Vb5dyJJXhAtQ4soUTAAshKATYB+f9X2p1n6VFHMQ@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T06:20:04Z","receivedAt":"2013-04-30T06:20:04Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 1:17 AM, Duy Nguyen wrote:\n> On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras\n> wrote:\n>> On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen wrote:\n>>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras\n>>> wrote:\n>>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n>>>> use 'git show @~1', and all that goody goodness.\n>>>\n>>> I like this. I haven't spent a lot of time on thinking about\n>>> ambiguation. But I think we're safe there. '@' is not overloaded much\n>>> like ':', '^' or '~'.\n>>>\n>>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>>>> 'master@'.\n>>>\n>>> I'm a bit reluctant to this. It looks like incomplete syntax to me as\n>>> '@' has always been followed by '{'. Can we have the lone '@' candy\n>>> but reject master@ and HEAD@? There's no actual gain in writing\n>>> master@ vs master@{0}.\n>>\n>> That's what I tried first, but it just didn't feel elegant to have one\n>> check for this case only. foo@ does follow naturally, and it doesn't\n>> hurt.\n>>\n>>>> +'@'::\n>>>> + '@' alone is a shortcut for 'HEAD'\n>>>> +\n>>>\n>>> And this does not explain about HEAD@ or master@. But because I prefer\n>>> the candy part only. This documentation part looks good :)\n>>\n>> Yeah, there's no point in documenting things that are not useful for\n>> the user. The fact that HEAD@ is translated to HEAD is just an\n>> implementation detail.\n>\n> Exactly. As it's implementation detail, it should not be exposed to\n> user as \"huh?\" moments when they type \"HEAD@\". I'm may be paranoid,\n> but if some user finds it nice (or just different) to try master@ in\n> scripts, then we change implementation details and master@ no longer\n> works, people could be upset. Undefined behavior syntax should be kept\n> to minimum. And to answer your other mail regarding the harmlessness\n> of @{-1}@, I'd rather pay some extra code than leave some loose ends\n> like that.\n\nI don't see it as a loose end.\n\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -443,8 +443,11 @@ static int get_sha1_basic(const char *str, int\nlen, unsigned char *sha1)\n return 0;\n\n empty_at = len && str[len-1] == '@';\n- if (empty_at)\n+ if (empty_at) {\n+ reflog_len = 0;\n len = len-1;\n+ goto next;\n+ }\n\n /* basic@{time or number or -number} format to query ref-log */\n reflog_len = at = 0;\n@@ -460,6 +463,7 @@ static int get_sha1_basic(const char *str, int\nlen, unsigned char *sha1)\n }\n }\n\n+next:\n\n-- \nFelipe Contreras\n"},{"id":"215969","messageId":"CACsJy8D6byr+ozGChScMr3rZ7dNGBbYzT5ROnvnTh4AC0x4dNA@mail.gmail.com","threadId":"33673","inReplyTo":"CAMP44s35HcjZ0sMjbOxHZt96v8S8eEFF+Y9JF_K9FKnFe-S9Xg@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-04-30T06:30:32Z","receivedAt":"2013-04-30T06:30:32Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras\n wrote:\n>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>>> 'master@'.\n>>\n>> I'm a bit reluctant to this. It looks like incomplete syntax to me as\n>> '@' has always been followed by '{'. Can we have the lone '@' candy\n>> but reject master@ and HEAD@? There's no actual gain in writing\n>> master@ vs master@{0}.\n>\n> That's what I tried first, but it just didn't feel elegant to have one\n> check for this case only. foo@ does follow naturally, and it doesn't\n> hurt.\n\nI'd say it's a side effect. This would stop both @{-1}@ and master@.\nWhitespace corruption expected.\n\n-- 8< --\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 3820f28..58bdb42 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -437,11 +437,13 @@ static int get_sha1_basic(const char *str, int\nlen, unsigned char *sha1)\n static const char *warn_msg = \"refname '%.*s' is ambiguous.\";\n char *real_ref = NULL;\n int refs_found = 0;\n- int at, reflog_len;\n+ int at, reflog_len, short_head;\n\n if (len == 40 && !get_sha1_hex(str, sha1))\n return 0;\n\n+ short_head = len == 1 && str[0] == '@';\n+\n /* basic@{time or number or -number} format to query ref-log */\n reflog_len = at = 0;\n if (len && str[len-1] == '}') {\n@@ -475,6 +477,8 @@ static int get_sha1_basic(const char *str, int\nlen, unsigned char *sha1)\n refs_found = dwim_ref(\"HEAD\", 4, sha1, &real_ref);\n } else if (reflog_len)\n refs_found = dwim_log(str, len, sha1, &real_ref);\n+ else if (short_head)\n+ refs_found = dwim_ref(\"HEAD\", 4, sha1, &real_ref);\n else\n refs_found = dwim_ref(str, len, sha1, &real_ref);\n\n-- 8< --\n--\nDuy\n"},{"id":"215970","messageId":"517F6E40.1040606@alum.mit.edu","threadId":"33673","inReplyTo":"CACsJy8D_gPpprETkAxf+eYp5DMt7uVt6nanCwthZO=vVfBT28Q@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-04-30T07:09:52Z","receivedAt":"2013-04-30T07:09:52Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 04/30/2013 07:54 AM, Duy Nguyen wrote:\n> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras\n> wrote:\n>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n>> use 'git show @~1', and all that goody goodness.\n> \n> I like this. I haven't spent a lot of time on thinking about\n> ambiguation. But I think we're safe there. '@' is not overloaded much\n> like ':', '^' or '~'.\n> \n>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>> 'master@'.\n> \n> I'm a bit reluctant to this. It looks like incomplete syntax to me as\n> '@' has always been followed by '{'. Can we have the lone '@' candy\n> but reject master@ and HEAD@? There's no actual gain in writing\n> master@ vs master@{0}.\n\nAccording to git-check-ref-format(1), an \"@\" character is currently\nlegal in a reference name as long as it is not followed by \"{\". As an\nexample, git-svn uses \"@\" in reference names (e.g.,\n\"refs/remotes/svn/tags/foo@56945\"), I believe when a Subversion branch\nor tag is deleted then re-created.\n\nThis is not to say that the rule can't be changed and/or that the\ngit-svn use of such tag names conflicts with the proposed new syntax.\nBut it can definitely not be excluded that the new pattern will be\nambiguous with refnames that are already in use \"in the wild\".\n\nAmusingly, it is already possible to define a reference or symbolic\nreference named \"@\". So all that you need to do is type\n\n git symbolic-ref -m \"Create @ alias for HEAD\" @ HEAD\n\nto get the shortcut that you want :-)\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"215971","messageId":"CALkWK0naGx6Vrb3_iZbXefQqmwOhaTSRXxBT6K-cheiUwr3Ptw@mail.gmail.com","threadId":"33673","inReplyTo":"517F6E40.1040606@alum.mit.edu","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T07:35:52Z","receivedAt":"2013-04-30T07:35:52Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Michael Haggerty wrote:\n> git symbolic-ref -m \"Create @ alias for HEAD\" @ HEAD\n\nI find this very interesting. I already have a symbolic ref H\npointing to HEAD, but it has some quirks: H@{u} complains that H is an\ninvalid branch for example. When I create the symbolic-ref @, I'm not\n_exactly_ creating a synonym for HEAD: @{u} works, not @@{u}.\n\nMany people are confused by this patch (reflog? HEAD@ versus master@?\nincomplete due to { omission?), and I'm not sure HEAD@ or master@ are\neven useful. This confusion can be avoided completely if the patch\nhas the exact same effect as symbolic-ref'ing @ to HEAD.\n"},{"id":"215972","messageId":"CAMP44s1OcDT_V_grAiVHH+G_c-UQg_Jv64Uybr+ZbUF7EQiW_w@mail.gmail.com","threadId":"33673","inReplyTo":"CACsJy8D6byr+ozGChScMr3rZ7dNGBbYzT5ROnvnTh4AC0x4dNA@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T07:55:45Z","receivedAt":"2013-04-30T07:55:45Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 1:30 AM, Duy Nguyen wrote:\n> On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras\n> wrote:\n>>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>>>> 'master@'.\n>>>\n>>> I'm a bit reluctant to this. It looks like incomplete syntax to me as\n>>> '@' has always been followed by '{'. Can we have the lone '@' candy\n>>> but reject master@ and HEAD@? There's no actual gain in writing\n>>> master@ vs master@{0}.\n>>\n>> That's what I tried first, but it just didn't feel elegant to have one\n>> check for this case only. foo@ does follow naturally, and it doesn't\n>> hurt.\n>\n> I'd say it's a side effect. This would stop both @{-1}@ and master@.\n> Whitespace corruption expected.\n\nYeah, this is what I did first, but if since there's no relation with\nanything else, '@' could be any other character.\n\n-- \nFelipe Contreras\n"},{"id":"215977","messageId":"CACsJy8ATWBuvqmjon7-s9KfPcWGHPUFbd6gHR2CqaOwHAgWZrg@mail.gmail.com","threadId":"33673","inReplyTo":"517F6E40.1040606@alum.mit.edu","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-04-30T10:12:08Z","receivedAt":"2013-04-30T10:12:08Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Apr 30, 2013 at 2:09 PM, Michael Haggerty wrote:\n> According to git-check-ref-format(1), an \"@\" character is currently\n> legal in a reference name as long as it is not followed by \"{\". As an\n> example, git-svn uses \"@\" in reference names (e.g.,\n> \"refs/remotes/svn/tags/foo@56945\"), I believe when a Subversion branch\n> or tag is deleted then re-created.\n\nThanks! I was looking for this document but couldn't remember its name.\n\n> Amusingly, it is already possible to define a reference or symbolic\n> reference named \"@\". So all that you need to do is type\n>\n> git symbolic-ref -m \"Create @ alias for HEAD\" @ HEAD\n>\n> to get the shortcut that you want :-)\n\nNot so amusingly (and off topic), why reading the code this patch\ntouches, I think if we have a ref whose last component is exactly 40\nchars and contains only [0-9a-fA-F], then we simply consider it sha-1\nand return without reading the ref.\n--\nDuy\n"},{"id":"215978","messageId":"CACsJy8C34vN7SB62-+Z3BNZeroTB_vm-n-NMhFRbAuBPQZFKcA@mail.gmail.com","threadId":"33673","inReplyTo":"CALkWK0naGx6Vrb3_iZbXefQqmwOhaTSRXxBT6K-cheiUwr3Ptw@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-04-30T10:16:39Z","receivedAt":"2013-04-30T10:16:39Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Apr 30, 2013 at 2:35 PM, Ramkumar Ramachandra\n wrote:\n> Michael Haggerty wrote:\n>> git symbolic-ref -m \"Create @ alias for HEAD\" @ HEAD\n>\n> I find this very interesting. I already have a symbolic ref H\n> pointing to HEAD, but it has some quirks: H@{u} complains that H is an\n> invalid branch for example. When I create the symbolic-ref @, I'm not\n> _exactly_ creating a synonym for HEAD: @{u} works, not @@{u}.\n\nHabits aside, why do you do H@{u} when @{u} is enough (and shorter)?\n--\nDuy\n"},{"id":"215981","messageId":"CALkWK0mftWaC0Mi6QYm+iPk8bMgmS05--nevVKdOeOM9sPyg5w@mail.gmail.com","threadId":"33673","inReplyTo":"CACsJy8C34vN7SB62-+Z3BNZeroTB_vm-n-NMhFRbAuBPQZFKcA@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T11:10:02Z","receivedAt":"2013-04-30T11:10:02Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Duy Nguyen wrote:\n> Habits aside, why do you do H@{u} when @{u} is enough (and shorter)?\n\nI don't. In the @{} spec, HEAD is implicit. My initial itch was that\nHEAD is not implicit in the ~ spec, and started off by thinking how\nwe could make HEAD implicit specifically for that case [1]. Since\nthen, we've realized that it's probably easier (and more useful) to\nhave a synonym for HEAD that works in all specs. As a side effect,\nmaster..@ will work too. I was looking into the repercussions of\nthis, and noticed that Michael's @ symref is not equivalent to my H\nsymref. I previously thought that all symrefs would behave in exactly\nthe same manner, but @ clearly seems to be a special case: I was\nmerely pointing this out with an example.\n\n[1]: http://article.gmane.org/gmane.comp.version-control.git/222343\n"},{"id":"216007","messageId":"7vppxcdjd1.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"CACsJy8D_gPpprETkAxf+eYp5DMt7uVt6nanCwthZO=vVfBT28Q@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T17:22:02Z","receivedAt":"2013-04-30T17:22:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras\n> wrote:\n>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n>> use 'git show @~1', and all that goody goodness.\n>\n> I like this. I haven't spent a lot of time on thinking about\n> ambiguation. But I think we're safe there. '@' is not overloaded much\n> like ':', '^' or '~'.\n>\n>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>> 'master@'.\n>\n> I'm a bit reluctant to this. It looks like incomplete syntax to me as\n> '@' has always been followed by '{'. Can we have the lone '@' candy\n> but reject master@ and HEAD@? There's no actual gain in writing\n> master@ vs master@{0}.\n\nOriginally I was going to say the same, but after thinking about it\na bit more, I changed my mind.\n\nIf you accept only \"@\" but not \"master@\", that behaviour needs a\nwrong world model to understand and justify (one of which is \"@ is a\nsynonym for HEAD\"). If your rule is \"In $anything@{$n}, you can\ndrop {$n} when $n==0\", then HEAD@{0} becomes HEAD@ and master@{0}\nbecomes master@, and @{0} becomes @ naturally.\n\nWe should make sure that the code rejects \"git update-ref @ foo\"\nbecause that is \"git update-ref @{0} ref\", by the way. I didn't\ncheck with Felipe's patch.\n\n>> +'@'::\n>> + '@' alone is a shortcut for 'HEAD'\n>> +\n\nI think this explanation sends a wrong message, hinting as if you\ncan expect \"update-ref @ master\", \"symbolic-ref @ refs/heads/next\"\netc. to do something sensible to HEAD.\n\nFelipe's original justification in the log message \"I want to drop\n{0}\" sounds closer to what is going on here.\n"},{"id":"216019","messageId":"CALkWK0=d-posGyemoBoWg+uxC-x3cwy8o8AQq2JYpq5r1sm2bg@mail.gmail.com","threadId":"33673","inReplyTo":"7vppxcdjd1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T17:37:51Z","receivedAt":"2013-04-30T17:37:51Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> If you accept only \"@\" but not \"master@\", that behaviour needs a\n> wrong world model to understand and justify (one of which is \"@ is a\n> synonym for HEAD\"). If your rule is \"In $anything@{$n}, you can\n> drop {$n} when $n==0\", then HEAD@{0} becomes HEAD@ and master@{0}\n> becomes master@, and @{0} becomes @ naturally.\n\nYou're telling me how to get @ from @{0}, but not how to get @ from\nHEAD. @{0}@{4} is meaningless, but HEAD@{4} is meaningful.\n"},{"id":"216020","messageId":"CALkWK0=GbhALxX0G-ka5oAbixoJv4uKPHAx5LPezgTyGxW_3MQ@mail.gmail.com","threadId":"33673","inReplyTo":"7vppxcdjd1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T17:40:46Z","receivedAt":"2013-04-30T17:40:46Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> If you accept only \"@\" but not \"master@\", that behaviour needs a\n> wrong world model to understand and justify (one of which is \"@ is a\n> synonym for HEAD\"). If your rule is \"In $anything@{$n}, you can\n> drop {$n} when $n==0\", then HEAD@{0} becomes HEAD@ and master@{0}\n> becomes master@, and @{0} becomes @ naturally.\n\nBesides, you're going in the wrong direction this time. You are\ntrying to fit an explanation to something that is useless. How is\nmaster@ useful?\n"},{"id":"216021","messageId":"CAMP44s0PcB7nu_67p=hfMy4Kb2iYTSp5ZT6y2Gn24OAtDzR_sw@mail.gmail.com","threadId":"33673","inReplyTo":"7vppxcdjd1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T17:47:57Z","receivedAt":"2013-04-30T17:47:57Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 12:22 PM, Junio C Hamano wrote:\n> Duy Nguyen writes:\n>\n>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras\n>> wrote:\n>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n>>> use 'git show @~1', and all that goody goodness.\n>>\n>> I like this. I haven't spent a lot of time on thinking about\n>> ambiguation. But I think we're safe there. '@' is not overloaded much\n>> like ':', '^' or '~'.\n>>\n>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>>> 'master@'.\n>>\n>> I'm a bit reluctant to this. It looks like incomplete syntax to me as\n>> '@' has always been followed by '{'. Can we have the lone '@' candy\n>> but reject master@ and HEAD@? There's no actual gain in writing\n>> master@ vs master@{0}.\n>\n> Originally I was going to say the same, but after thinking about it\n> a bit more, I changed my mind.\n>\n> If you accept only \"@\" but not \"master@\", that behaviour needs a\n> wrong world model to understand and justify (one of which is \"@ is a\n> synonym for HEAD\"). If your rule is \"In $anything@{$n}, you can\n> drop {$n} when $n==0\", then HEAD@{0} becomes HEAD@ and master@{0}\n> becomes master@, and @{0} becomes @ naturally.\n>\n> We should make sure that the code rejects \"git update-ref @ foo\"\n> because that is \"git update-ref @{0} ref\", by the way. I didn't\n> check with Felipe's patch.\n\nHmm, with or without my patch 'git update @ foo' does nothing, same\nwith 'git update blah foo'. No error, no non-zero exit code, just\ndoesn't do anything.\n\n>>> +'@'::\n>>> + '@' alone is a shortcut for 'HEAD'\n>>> +\n>\n> I think this explanation sends a wrong message, hinting as if you\n> can expect \"update-ref @ master\", \"symbolic-ref @ refs/heads/next\"\n> etc. to do something sensible to HEAD.\n\nWhy would it? This is Documentation/revisions.txt, 'update-ref' has\nnothing to do with that.\n\nThis hints that the user can do \"update-ref @\" as much as the\nparagraph below thins that that user can do \"update-ref\nmaster@{today}\".\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"216027","messageId":"7v8v3zewfi.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"20130430005304.GG24467@google.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T17:54:25Z","receivedAt":"2013-04-30T17:54:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>\n>>> Never-mind, now I see the difference, still, I don't think it's\n>>> relevant for this patch.\n>>\n>> I don't either. With the precedence of @{u}, @ does not need to have\n>> anything to do with a reflog. It is just a random letter that casts\n>> a magic spell.\n>\n> I thought the convention was \"^{...} is for operators that act on\n> objects, @{...} for operators that act on refs or symrefs\".\n\nAlmost. You can ask \"git rev-parse --symbolic-full-name\" to see\nthat @{-1} is still a ref, but @{1} is _not_ a ref (it is a concrete\nrevision that you cannot run 'update-ref' on).\n"},{"id":"216028","messageId":"7v1u9rewc1.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"CALkWK0=GbhALxX0G-ka5oAbixoJv4uKPHAx5LPezgTyGxW_3MQ@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T17:56:30Z","receivedAt":"2013-04-30T17:56:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Junio C Hamano wrote:\n>> If you accept only \"@\" but not \"master@\", that behaviour needs a\n>> wrong world model to understand and justify (one of which is \"@ is a\n>> synonym for HEAD\"). If your rule is \"In $anything@{$n}, you can\n>> drop {$n} when $n==0\", then HEAD@{0} becomes HEAD@ and master@{0}\n>> becomes master@, and @{0} becomes @ naturally.\n>\n> Besides, you're going in the wrong direction this time. You are\n> trying to fit an explanation to something that is useless. How is\n> master@ useful?\n\nHow else would you explain why \"rev-parse --symbolic-full-name @\"\ndoes not make sense and \"update-ref @\" does not update HEAD?\n"},{"id":"216029","messageId":"20130430175635.GA1972@sigill.intra.peff.net","threadId":"33673","inReplyTo":"CAMP44s0PcB7nu_67p=hfMy4Kb2iYTSp5ZT6y2Gn24OAtDzR_sw@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-30T17:56:35Z","receivedAt":"2013-04-30T17:56:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 30, 2013 at 12:47:57PM -0500, Felipe Contreras wrote:\n\n> > We should make sure that the code rejects \"git update-ref @ foo\"\n> > because that is \"git update-ref @{0} ref\", by the way. I didn't\n> > check with Felipe's patch.\n> \n> Hmm, with or without my patch 'git update @ foo' does nothing, same\n> with 'git update blah foo'. No error, no non-zero exit code, just\n> doesn't do anything.\n\nAre you sure?\n\n $ git version\n git version 1.8.2\n\n $ git update-ref @ foo\n fatal: foo: not a valid SHA1\n\n $ git update-ref @ origin/master\n $ echo $?\n 0\n $ cat .git/@\n 89740333e8d398f1da701e9023675321bbb9a85b\n\n-Peff\n"},{"id":"216031","messageId":"CALkWK0kXSugXTKWy7_6WT_3UnwVhzyCJNR=QS-4K6vWrU61m4w@mail.gmail.com","threadId":"33673","inReplyTo":"7v1u9rewc1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T18:04:05Z","receivedAt":"2013-04-30T18:04:05Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> How else would you explain why \"rev-parse --symbolic-full-name @\"\n> does not make sense\n\nIt does make sense. (Try it with my patch) [*1*]\n\n> and \"update-ref @\" does not update HEAD?\n\nWhy should update-ref update HEAD? I'm asking it to update the\nsymbolic-ref override .git/@.\n\n[Footnote]\n\n*1* I made a mistake in the commit message when I said that git\nsymbolic-ref @ HEAD had the exact same effect.\n"},{"id":"216033","messageId":"CAMP44s0C-O+c_n+46ns8B-zXLUGfyEEOmdDyWs63nX+ZNoOvkQ@mail.gmail.com","threadId":"33673","inReplyTo":"7v8v3zewfi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T18:17:24Z","receivedAt":"2013-04-30T18:17:24Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 12:54 PM, Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>\n>> Junio C Hamano wrote:\n>>> Felipe Contreras writes:\n>>\n>>>> Never-mind, now I see the difference, still, I don't think it's\n>>>> relevant for this patch.\n>>>\n>>> I don't either. With the precedence of @{u}, @ does not need to have\n>>> anything to do with a reflog. It is just a random letter that casts\n>>> a magic spell.\n>>\n>> I thought the convention was \"^{...} is for operators that act on\n>> objects, @{...} for operators that act on refs or symrefs\".\n>\n> Almost. You can ask \"git rev-parse --symbolic-full-name\" to see\n> that @{-1} is still a ref, but @{1} is _not_ a ref (it is a concrete\n> revision that you cannot run 'update-ref' on).\n\nThis has nothing to do with this documentation.\n\ndiff --git a/Documentation/git-check-ref-format.txt\nb/Documentation/git-check-ref-format.txt\nindex ec1739a..4764975 100644\n--- a/Documentation/git-check-ref-format.txt\n+++ b/Documentation/git-check-ref-format.txt\n@@ -52,7 +52,7 @@ Git imposes the following rules on how references are named:\n\n . They cannot end with a dot `.`.\n\n-. They cannot contain a sequence `@{`.\n+. They cannot contain a sequence `@{` or end with `@`.\n\n . They cannot contain a `\\`.\n\ndiff --git a/refs.c b/refs.c\nindex de2d8eb..99ac4f6 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -95,6 +95,8 @@ int check_refname_format(const char *refname, int flags)\n\n if (refname[component_len - 1] == '.')\n return -1; /* Refname ends with '.'. */\n+ if (refname[component_len - 1] == '@')\n+ return -1; /* Refname ends with '@'. */\n if (!(flags & REFNAME_ALLOW_ONELEVEL) && component_count < 2)\n return -1; /* Refname has only one component. */\n return 0;\n\n% git update-ref master@ master\nfatal: Cannot lock the ref 'master@'.\n\n-- \nFelipe Contreras\n"},{"id":"216034","messageId":"CAMP44s22Gz=fjregUE37r-V7R+eC_vLhdkefTybEpPDm680NBQ@mail.gmail.com","threadId":"33673","inReplyTo":"20130430175635.GA1972@sigill.intra.peff.net","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T18:18:16Z","receivedAt":"2013-04-30T18:18:16Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 12:56 PM, Jeff King wrote:\n> On Tue, Apr 30, 2013 at 12:47:57PM -0500, Felipe Contreras wrote:\n>\n>> > We should make sure that the code rejects \"git update-ref @ foo\"\n>> > because that is \"git update-ref @{0} ref\", by the way. I didn't\n>> > check with Felipe's patch.\n>>\n>> Hmm, with or without my patch 'git update @ foo' does nothing, same\n>> with 'git update blah foo'. No error, no non-zero exit code, just\n>> doesn't do anything.\n>\n> Are you sure?\n>\n> $ git version\n> git version 1.8.2\n>\n> $ git update-ref @ foo\n> fatal: foo: not a valid SHA1\n>\n> $ git update-ref @ origin/master\n> $ echo $?\n> 0\n> $ cat .git/@\n> 89740333e8d398f1da701e9023675321bbb9a85b\n\nRight. I don't know why I expected it to show in 'git show-ref'.\n\n-- \nFelipe Contreras\n"},{"id":"216043","messageId":"CAMP44s28aQ7aDCBk=TwPJsb4xoyQMfx85DhaNB4P+XzbgctoPw@mail.gmail.com","threadId":"33673","inReplyTo":"CALkWK0=GbhALxX0G-ka5oAbixoJv4uKPHAx5LPezgTyGxW_3MQ@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T18:20:51Z","receivedAt":"2013-04-30T18:20:51Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 12:40 PM, Ramkumar Ramachandra\n wrote:\n> Junio C Hamano wrote:\n>> If you accept only \"@\" but not \"master@\", that behaviour needs a\n>> wrong world model to understand and justify (one of which is \"@ is a\n>> synonym for HEAD\"). If your rule is \"In $anything@{$n}, you can\n>> drop {$n} when $n==0\", then HEAD@{0} becomes HEAD@ and master@{0}\n>> becomes master@, and @{0} becomes @ naturally.\n>\n> Besides, you're going in the wrong direction this time. You are\n> trying to fit an explanation to something that is useless. How is\n> master@ useful?\n\nIt's not. The same way master^0^0~4 is not useful, yet it's works;\nit's a logical result from the syntax.\n\n-- \nFelipe Contreras\n"},{"id":"216041","messageId":"CALkWK0m6VeHxwi4ytSFrib2r5GS1acph+WA+YXD80KuBhr74+g@mail.gmail.com","threadId":"33673","inReplyTo":"CAMP44s28aQ7aDCBk=TwPJsb4xoyQMfx85DhaNB4P+XzbgctoPw@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T18:45:44Z","receivedAt":"2013-04-30T18:45:44Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> It's not. The same way master^0^0~4 is not useful, yet it's works;\n> it's a logical result from the syntax.\n\nIt's logical if you explain @ as a shortcut for @{0}, and make\n@{0}@{1} resolve somehow [*1*].\n\n[Footnotes]\n\n*1*: The best I can do is @{0} is like a ref (while @{>0} are\nrevisions), but you can't update-ref or symbolic-ref it. Kludgy,\ndon't you think?\n"},{"id":"216044","messageId":"CALkWK0ns5xvM6otRe2X+4=q_KSO7U74ZVX4PQ32mFmNMdg8B+w@mail.gmail.com","threadId":"33673","inReplyTo":"CALkWK0naGx6Vrb3_iZbXefQqmwOhaTSRXxBT6K-cheiUwr3Ptw@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T18:54:58Z","receivedAt":"2013-04-30T18:54:58Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> I'm not\n> _exactly_ creating a synonym for HEAD: @{u} works, not @@{u}.\n\nTurns out this is actually a parsing-bug in @{u}. @@{5.minutes.ago}\nand @@{5} work just fine.\n"},{"id":"216048","messageId":"7vhaindcuk.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"7vppxcdjd1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T19:42:43Z","receivedAt":"2013-04-30T19:42:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Duy Nguyen writes:\n>\n>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras\n>> wrote:\n>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n>>> use 'git show @~1', and all that goody goodness.\n>>\n>> I like this. I haven't spent a lot of time on thinking about\n>> ambiguation. But I think we're safe there. '@' is not overloaded much\n>> like ':', '^' or '~'.\n>>\n>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>>> 'master@'.\n>>\n>> I'm a bit reluctant to this. It looks like incomplete syntax to me as\n>> '@' has always been followed by '{'. Can we have the lone '@' candy\n>> but reject master@ and HEAD@? There's no actual gain in writing\n>> master@ vs master@{0}.\n>\n> Originally I was going to say the same, but after thinking about it\n> a bit more, I changed my mind.\n\nLet me change my mind once again ;-)\n\nAs @ has been a valid character in a ref, I think \"git show master@\"\nand \"git show HEAD@\" _should_ error out, not because they suffix\n'master' and 'HEAD\" in a funny way, but simply because there is no\nbranch called 'master@' (i.e. 'git for-each-ref | grep master@'\nyields empty). After you run \"git branch master@ master~26\", you\nshould see \"git show master@\" not to error out, because that is just\nthe name of a branch with somewhat an unusual name.\n\nAnd we can still have \"git show @\" to do \"git show HEAD\", based on a\nworld model completely different from I (incorrectly) advocated in\nthe message I am replying to.\n\nThe rule would be \"You should be able to say '@' where-ever you\ncurrently say HEAD\" (aka '@' is a short-hand for 'HEAD').\n\nThat means \"git checout @\" should work the same way as \"git checkout\nHEAD\", \"git log @~4\" would work the same way as \"git log HEAD~4\",\n\"git update-ref @ $(git rev-parse master)\" should update the HEAD\nwithout creating $GIT_DIR/@, etc.\n\nYou can't go any simpler than that rule, and there is no room for\nconfusion if that rule is properly implemented.\n\nHmm?\n"},{"id":"216050","messageId":"CALkWK0kUOEygRE8uMJbW=fOV6iGPAap+mbS7mysTHT3Ri+9eGg@mail.gmail.com","threadId":"33673","inReplyTo":"7vhaindcuk.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T19:53:29Z","receivedAt":"2013-04-30T19:53:29Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> [...]\n> You can't go any simpler than that rule, and there is no room for\n> confusion if that rule is properly implemented.\n\nIn other words: the sequence \"@\" is short for \"HEAD\". Isn't that\n_exactly_ what I implemented in my two-liner?\n\nHowever, I'm tilting towards respecting .git/@ as a manual override.\nWhy? Because we'd have to either claim that git symbolic-ref @ HEAD\nis a noop, or deny it altogether (by saying that @ is not a valid\nsymbolic ref). The latter approach obviously sounds more sensible,\nbut I don't like unnecessarily eating up @.\n"},{"id":"216052","messageId":"7v8v3zdc2m.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"7vhaindcuk.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T19:59:29Z","receivedAt":"2013-04-30T19:59:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> The rule would be \"You should be able to say '@' where-ever you\n> currently say HEAD\" (aka '@' is a short-hand for 'HEAD').\n>\n> That means \"git checout @\" should work the same way as \"git checkout\n> HEAD\", \"git log @~4\" would work the same way as \"git log HEAD~4\",\n> \"git update-ref @ $(git rev-parse master)\" should update the HEAD\n> without creating $GIT_DIR/@, etc.\n>\n> You can't go any simpler than that rule, and there is no room for\n> confusion if that rule is properly implemented.\n>\n> Hmm?\n\nI personally would not mind an easier-to-implement rule that says\n\"You can say '@' to mean HEAD^0, i.e. the object name of the commit\nat the tip of your current branch\". That would make sure that\nnobody would expect \"git update-ref @ $(git rev-parse master~4)\" to\nwork.\n"},{"id":"216054","messageId":"7v4nendbry.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"CALkWK0kUOEygRE8uMJbW=fOV6iGPAap+mbS7mysTHT3Ri+9eGg@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T20:05:53Z","receivedAt":"2013-04-30T20:05:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> In other words: the sequence \"@\" is short for \"HEAD\".\n\nThat is saying a very different thing. master@{4.days} is not short\nfor masterHEAD{4.days}.\n\n> Isn't that\n> _exactly_ what I implemented in my two-liner?\n\nI dunno. \n\nAs design and semantics look still fuzzy (the primary one I am not\nsure about is if @ is a ref or just a revision), even though the\ndesire to have _something_ seem to be popular, I am not particulary\ninterested in looking at an alternative patch. I want to see the\nright semantics first.\n"},{"id":"216060","messageId":"CALkWK0k9Gix4_x-VKry2a-hZL-j0ROGGLiiYV9NyE+1A-VxQOA@mail.gmail.com","threadId":"33673","inReplyTo":"7v4nendbry.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T20:37:32Z","receivedAt":"2013-04-30T20:37:32Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Ramkumar Ramachandra writes:\n>\n>> In other words: the sequence \"@\" is short for \"HEAD\".\n>\n> That is saying a very different thing. master@{4.days} is not short\n> for masterHEAD{4.days}.\n\nI meant after ^, ~, @{} have been peeled off. Just before resolving\nwhat's left.\n\n> As design and semantics look still fuzzy (the primary one I am not\n> sure about is if @ is a ref or just a revision), even though the\n> desire to have _something_ seem to be popular, I am not particulary\n> interested in looking at an alternative patch. I want to see the\n> right semantics first.\n\nI wanted to explain it through an implementation, but okay. In your\nproposal, @ is a special ref: it behaves like a ref in a rev spec, but\ncannot be update-ref'ed or symbolic-ref'ed. This is probably the best\nwe can do, unless we want to emulate a full ref (I'm not sure how\nuseful the .git/@ override will even be).\n"},{"id":"216078","messageId":"CAMP44s2FqsK-46QVjHYFkWTqCkcAHZUw+XEbZdV6y=5+sZCJ=A@mail.gmail.com","threadId":"33673","inReplyTo":"CALkWK0m6VeHxwi4ytSFrib2r5GS1acph+WA+YXD80KuBhr74+g@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T22:08:32Z","receivedAt":"2013-04-30T22:08:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 1:45 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> It's not. The same way master^0^0~4 is not useful, yet it's works;\n>> it's a logical result from the syntax.\n>\n> It's logical if you explain @ as a shortcut for @{0}, and make\n> @{0}@{1} resolve somehow [*1*].\n\nBut @{-1}@{1} does resolve, and so does @{u}@{1}. So @ would be a\nshortcut of @{this ref}, a no-op on the ref.\n\n-- \nFelipe Contreras\n"},{"id":"216080","messageId":"CAMP44s2S4AtZUfH4NWCLt=p49QXeYSZKELYbahpBUgDofaFMsw@mail.gmail.com","threadId":"33673","inReplyTo":"7vhaindcuk.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T22:17:48Z","receivedAt":"2013-04-30T22:17:48Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 2:42 PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> Duy Nguyen writes:\n>>\n>>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras\n>>> wrote:\n>>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can\n>>>> use 'git show @~1', and all that goody goodness.\n>>>\n>>> I like this. I haven't spent a lot of time on thinking about\n>>> ambiguation. But I think we're safe there. '@' is not overloaded much\n>>> like ':', '^' or '~'.\n>>>\n>>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with\n>>>> 'master@'.\n>>>\n>>> I'm a bit reluctant to this. It looks like incomplete syntax to me as\n>>> '@' has always been followed by '{'. Can we have the lone '@' candy\n>>> but reject master@ and HEAD@? There's no actual gain in writing\n>>> master@ vs master@{0}.\n>>\n>> Originally I was going to say the same, but after thinking about it\n>> a bit more, I changed my mind.\n>\n> Let me change my mind once again ;-)\n>\n> As @ has been a valid character in a ref, I think \"git show master@\"\n> and \"git show HEAD@\" _should_ error out, not because they suffix\n> 'master' and 'HEAD\" in a funny way, but simply because there is no\n> branch called 'master@' (i.e. 'git for-each-ref | grep master@'\n> yields empty). After you run \"git branch master@ master~26\", you\n> should see \"git show master@\" not to error out, because that is just\n> the name of a branch with somewhat an unusual name.\n\nThere is also no branch named master@{0}. And there are no branches\nwith @{ in them, because we forbid them. So the question is what do we\nwant to forbid? If we don't want to forbid 'master@', then sure\n'master@' should not evaluate to 'master'.\n\n> And we can still have \"git show @\" to do \"git show HEAD\", based on a\n> world model completely different from I (incorrectly) advocated in\n> the message I am replying to.\n>\n> The rule would be \"You should be able to say '@' where-ever you\n> currently say HEAD\" (aka '@' is a short-hand for 'HEAD').\n>\n> That means \"git checout @\" should work the same way as \"git checkout\n> HEAD\", \"git log @~4\" would work the same way as \"git log HEAD~4\",\n> \"git update-ref @ $(git rev-parse master)\" should update the HEAD\n> without creating $GIT_DIR/@, etc.\n>\n> You can't go any simpler than that rule, and there is no room for\n> confusion if that rule is properly implemented.\n\nI disagree. I can do 'git log @{-1}-4', but I cannot do 'git\nupdate-ref @{-1}'. Why? Because the '@' notation is for revision\nparsing, and 'git update-ref' doesn't do revision parsing.\n\nI'd say, everywhere where you could do @{-1}, you should be able to do @.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"216083","messageId":"7vsj27ac2a.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"CAMP44s2S4AtZUfH4NWCLt=p49QXeYSZKELYbahpBUgDofaFMsw@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T22:27:57Z","receivedAt":"2013-04-30T22:27:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> That means \"git checout @\" should work the same way as \"git checkout\n>> HEAD\", \"git log @~4\" would work the same way as \"git log HEAD~4\",\n>> \"git update-ref @ $(git rev-parse master)\" should update the HEAD\n>> without creating $GIT_DIR/@, etc.\n>>\n>> You can't go any simpler than that rule, and there is no room for\n>> confusion if that rule is properly implemented.\n>\n> I disagree. I can do 'git log @{-1}-4', but I cannot do 'git\n> update-ref @{-1}'. Why? Because the '@' notation is for revision\n> parsing, and 'git update-ref' doesn't do revision parsing.\n>\n> I'd say, everywhere where you could do @{-1}, you should be able to do @.\n\nYes, @{-1} is about a ref, the branch that you were on previously.\nThat is why you can do\n\n\tgit checkout fc/at-head\n git checkout master...\n git am -s <./+fc-updated-at-head-series.mbox\n git co -B @{-1}\n\nWe wouldn't be able to do the last step, if @{-1} evaluated it down\nto the object name, losing the refname.\n\nIf \"update-ref @{-1}\" does not grok @{-1}, probably there needs a\ncall to interpret_nth_prior_checkout() in the codepath.\n"},{"id":"216086","messageId":"CAMP44s3=frHWUh8rQ5kTooUJqwAtkEG37MaeY3Ho6G7-kwZQ_w@mail.gmail.com","threadId":"33673","inReplyTo":"7vsj27ac2a.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T22:38:02Z","receivedAt":"2013-04-30T22:38:02Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 5:27 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>>> That means \"git checout @\" should work the same way as \"git checkout\n>>> HEAD\", \"git log @~4\" would work the same way as \"git log HEAD~4\",\n>>> \"git update-ref @ $(git rev-parse master)\" should update the HEAD\n>>> without creating $GIT_DIR/@, etc.\n>>>\n>>> You can't go any simpler than that rule, and there is no room for\n>>> confusion if that rule is properly implemented.\n>>\n>> I disagree. I can do 'git log @{-1}-4', but I cannot do 'git\n>> update-ref @{-1}'. Why? Because the '@' notation is for revision\n>> parsing, and 'git update-ref' doesn't do revision parsing.\n>>\n>> I'd say, everywhere where you could do @{-1}, you should be able to do @.\n>\n> Yes, @{-1} is about a ref, the branch that you were on previously.\n> That is why you can do\n>\n> git checkout fc/at-head\n> git checkout master...\n> git am -s <./+fc-updated-at-head-series.mbox\n> git co -B @{-1}\n>\n> We wouldn't be able to do the last step, if @{-1} evaluated it down\n> to the object name, losing the refname.\n>\n> If \"update-ref @{-1}\" does not grok @{-1}, probably there needs a\n> call to interpret_nth_prior_checkout() in the codepath.\n\nMaybe, but the closest thing would be dwim_ref(), which would also use\nrev parsing rules, so there might ambiguous refs.\n\nSince 'update-ref master' updates the 'master' ref, and not\n'refs/heads/master' (IOW; no parsing at all), I think it makes sense\nthat @{-1} is not parsed, and neither is @.\n\nIf the user really really wants rev parsing, she can use 'git rev-parse'.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"216088","messageId":"7vbo8vabet.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"CAMP44s3=frHWUh8rQ5kTooUJqwAtkEG37MaeY3Ho6G7-kwZQ_w@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T22:42:02Z","receivedAt":"2013-04-30T22:42:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Since 'update-ref master' updates the 'master' ref, and not\n> 'refs/heads/master' (IOW; no parsing at all), I think it makes sense\n> that @{-1} is not parsed, and neither is @.\n\nThat is a very valid point.\n\nWhat should \"rev-parse --symbolic-full-name @\" say?\n"},{"id":"216091","messageId":"CAMP44s02QkL7QAuHHm_uT6B4QCzk9Mur0_w_D8t2A2u1go2F8A@mail.gmail.com","threadId":"33673","inReplyTo":"7vbo8vabet.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T22:53:50Z","receivedAt":"2013-04-30T22:53:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 5:42 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> Since 'update-ref master' updates the 'master' ref, and not\n>> 'refs/heads/master' (IOW; no parsing at all), I think it makes sense\n>> that @{-1} is not parsed, and neither is @.\n>\n> That is a very valid point.\n>\n> What should \"rev-parse --symbolic-full-name @\" say?\n\nProbably the same as 'rev-parse --symbolic-full-name HEAD' (it doesn't\nwith my patch).\n\n-- \nFelipe Contreras\n"},{"id":"216092","messageId":"CAMP44s3L6X=iWK7S-JFqp42PmNx4xbh-GnPJpAgur4FGoZYNbg@mail.gmail.com","threadId":"33673","inReplyTo":"CAMP44s02QkL7QAuHHm_uT6B4QCzk9Mur0_w_D8t2A2u1go2F8A@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T23:00:52Z","receivedAt":"2013-04-30T23:00:52Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 5:53 PM, Felipe Contreras\n wrote:\n> On Tue, Apr 30, 2013 at 5:42 PM, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>>\n>>> Since 'update-ref master' updates the 'master' ref, and not\n>>> 'refs/heads/master' (IOW; no parsing at all), I think it makes sense\n>>> that @{-1} is not parsed, and neither is @.\n>>\n>> That is a very valid point.\n>>\n>> What should \"rev-parse --symbolic-full-name @\" say?\n>\n> Probably the same as 'rev-parse --symbolic-full-name HEAD' (it doesn't\n> with my patch).\n\nThe gist of my patch can be dropped, this does the trick:\n\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -965,6 +965,21 @@ int get_sha1_mb(const char *name, unsigned char *sha1)\n return st;\n }\n\n+static int interpret_empty_at(const char *name, int namelen, int len,\nstruct strbuf *buf)\n+{\n+ if (namelen - len < 1 || name[len + 1] == '{')\n+ return -1;\n+\n+ strbuf_reset(buf);\n+ if (len == 0) {\n+ strbuf_add(buf, \"HEAD\", 4);\n+ return 1;\n+ } else {\n+ strbuf_add(buf, name, len);\n+ return len + 1;\n+ }\n+}\n+\n static int reinterpret(const char *name, int namelen, int len, struct\nstrbuf *buf)\n {\n /* we have extra data, which might need further processing */\n@@ -1025,9 +1040,15 @@ int interpret_branch_name(const char *name,\nstruct strbuf *buf)\n cp = strchr(name, '@');\n if (!cp)\n return -1;\n+\n+ len = interpret_empty_at(name, namelen, cp - name, buf);\n+ if (len > 0)\n+ return reinterpret(name, namelen, len, buf);\n+\n tmp_len = upstream_mark(cp, namelen - (cp - name));\n if (!tmp_len)\n return -1;\n+\n len = cp + tmp_len - name;\n cp = xstrndup(name, cp - name);\n upstream = branch_get(*cp ? cp : NULL);\n\n-- \nFelipe Contreras\n"},{"id":"216095","messageId":"CAMP44s3QT5z1iWsm0cvQDfmZBp_kWbXatQKGaj8H3kzgdK=QFw@mail.gmail.com","threadId":"33673","inReplyTo":"CAMP44s3L6X=iWK7S-JFqp42PmNx4xbh-GnPJpAgur4FGoZYNbg@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T23:19:46Z","receivedAt":"2013-04-30T23:19:46Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 6:00 PM, Felipe Contreras\n wrote:\n\n> +static int interpret_empty_at(const char *name, int namelen, int len,\n> struct strbuf *buf)\n> +{\n> + if (namelen - len < 1 || name[len + 1] == '{')\n> + return -1;\n> +\n> + strbuf_reset(buf);\n> + if (len == 0) {\n> + strbuf_add(buf, \"HEAD\", 4);\n> + return 1;\n> + } else {\n> + strbuf_add(buf, name, len);\n> + return len + 1;\n> + }\n> +}\n\nHmm, it's not correct, and besides, if we don't parse 'master@', it's\nmuch simpler:\n\n/* parse @something syntax, when 'something' is not {.*} */\nstatic int interpret_empty_at(const char *name, int namelen, int len,\nstruct strbuf *buf)\n{\n\tif (len || (namelen > 1 && name[1] == '{'))\n\t\treturn -1;\n\n\tstrbuf_reset(buf);\n\tstrbuf_add(buf, \"HEAD\", 4);\n\treturn 1;\n}\n\n-- \nFelipe Contreras\n"},{"id":"216096","messageId":"7vy5bz8uw7.fsf@alter.siamese.dyndns.org","threadId":"33673","inReplyTo":"CAMP44s3QT5z1iWsm0cvQDfmZBp_kWbXatQKGaj8H3kzgdK=QFw@mail.gmail.com","subject":"Re: [PATCH] Add new @ shortcut for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T23:24:08Z","receivedAt":"2013-04-30T23:24:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Tue, Apr 30, 2013 at 6:00 PM, Felipe Contreras\n> wrote:\n>\n>> +static int interpret_empty_at(const char *name, int namelen, int len,\n>> struct strbuf *buf)\n>> +{\n>> + if (namelen - len < 1 || name[len + 1] == '{')\n>> + return -1;\n>> +\n>> + strbuf_reset(buf);\n>> + if (len == 0) {\n>> + strbuf_add(buf, \"HEAD\", 4);\n>> + return 1;\n>> + } else {\n>> + strbuf_add(buf, name, len);\n>> + return len + 1;\n>> + }\n>> +}\n>\n> Hmm, it's not correct, and besides, if we don't parse 'master@', it's\n> much simpler:\n>\n> /* parse @something syntax, when 'something' is not {.*} */\n> static int interpret_empty_at(const char *name, int namelen, int len,\n> struct strbuf *buf)\n> {\n> \tif (len || (namelen > 1 && name[1] == '{'))\n> \t\treturn -1;\n>\n> \tstrbuf_reset(buf);\n> \tstrbuf_add(buf, \"HEAD\", 4);\n> \treturn 1;\n> }\n\nI'm done with today's integration cycle and pushed the series\nwithout these updates out on 'pu'. Hopefully you will have a \"drop\nthe last N and replace them with this\" update after finishing these\nexperiments by tomorrow? ;-)\n\nThanks.\n\nPeople who wanted to see some form of typesaver for HEAD, please\npoke at the implementation and see if there are cases where @ should\nbe interpreted as HEAD replacement but isn't (or vice-versa).\n"}]}