{"thread":{"id":"28086","subject":"can we have @{U} as an alias for @{u}","startedAt":"2011-08-13T07:57:24Z","lastAt":"2011-08-19T18:54:57Z","messageCount":8,"participants":["Sitaram Chamarty","Conrad Irwin","Junio C Hamano","Nguyen Thai Ngoc Duy","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"173442","messageId":"CAMK1S_hZkdXiQb_UTB=snLAXPmo5yrCnFaQFHZqYq5AXqOgWng@mail.gmail.com","threadId":"28086","inReplyTo":null,"subject":"can we have @{U} as an alias for @{u}","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2011-08-13T07:57:24Z","receivedAt":"2011-08-13T07:57:24Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"Would be so much faster to type if uppercase U were also allowed...\n\n-- \nSitaram\n"},{"id":"173470","messageId":"1313287071-7851-1-git-send-email-conrad.irwin@gmail.com","threadId":"28086","inReplyTo":"CAMK1S_hZkdXiQb_UTB=snLAXPmo5yrCnFaQFHZqYq5AXqOgWng@mail.gmail.com","subject":"[PATCH] rev-parse: Allow @{U} as a synonym for @{u}","fromName":"Conrad Irwin","fromEmail":"conrad.irwin@gmail.com","sentAt":"2011-08-14T01:57:51Z","receivedAt":"2011-08-14T01:57:51Z","isPatch":true,"sender":{"key":"conrad.irwin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94272?v=4"},"body":"This facilitates specifying the upstream of a branch if you have\ndifficulty synchronising your shift-key and other characters, if you\njust want to SHOUT at git, or if you're expecting consistency with\n@{1DAY}.\n\nSigned-off-by: Conrad Irwin \n---\n Documentation/revisions.txt | 4 ++--\n sha1_name.c | 2 +-\n t/t1507-rev-parse-upstream.sh | 8 ++++++++\n 3 files changed, 11 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/revisions.txt b/Documentation/revisions.txt\nindex b290b61..c89d74d 100644\n--- a/Documentation/revisions.txt\n+++ b/Documentation/revisions.txt\n@@ -87,8 +87,8 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.\n before the current one.\n \n '@\\{upstream\\}', e.g. 'master@\\{upstream\\}', '@\\{u\\}'::\n- The suffix '@\\{upstream\\}' to a ref (short form '@\\{u\\}') refers to\n- the branch the ref is set to build on top of. A missing ref defaults\n+ The suffix '@\\{upstream\\}' to a ref (short form '@\\{u\\}', or '@\\{U\\}')\n+ refers to the branch the ref is set to build on top of. A missing ref defaults\n to the current branch.\n \n '{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0'::\ndiff --git a/sha1_name.c b/sha1_name.c\nindex ff5992a..ef4b77f 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -334,7 +334,7 @@ static inline int upstream_mark(const char *string, int len)\n \tfor (i = 0; i < ARRAY_SIZE(suffix); i++) {\n \t\tint suffix_len = strlen(suffix[i]);\n \t\tif (suffix_len <= len\n-\t\t && !memcmp(string, suffix[i], suffix_len))\n+\t\t && !strncasecmp(string, suffix[i], suffix_len))\n \t\t\treturn suffix_len;\n \t}\n \treturn 0;\ndiff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh\nindex a455551..5be605f 100755\n--- a/t/t1507-rev-parse-upstream.sh\n+++ b/t/t1507-rev-parse-upstream.sh\n@@ -37,6 +37,14 @@ test_expect_success '@{u} resolves to correct full name' '\n \ttest refs/remotes/origin/master = \"$(full_name @{u})\"\n '\n \n+test_expect_success '@{U} resolves to correct full name' '\n+\ttest refs/remotes/origin/master = \"$(full_name @{U})\"\n+'\n+\n+test_expect_success '@{Upstream} resolves to correct full name' '\n+\ttest refs/remotes/origin/master = \"$(full_name @{Upstream})\"\n+'\n+\n test_expect_success 'my-side@{upstream} resolves to correct full name' '\n \ttest refs/remotes/origin/side = \"$(full_name my-side@{u})\"\n '\n-- \n1.7.6.448.gc83e3.dirty\n"},{"id":"173702","messageId":"7vhb5fd4zy.fsf@alter.siamese.dyndns.org","threadId":"28086","inReplyTo":"1313287071-7851-1-git-send-email-conrad.irwin@gmail.com","subject":"Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-17T22:53:37Z","receivedAt":"2011-08-17T22:53:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Conrad Irwin writes:\n\n> This facilitates specifying the upstream of a branch if you have\n> difficulty synchronising your shift-key and other characters, if you\n> just want to SHOUT at git, or if you're expecting consistency with\n> @{1DAY}.\n\n> +test_expect_success '@{U} resolves to correct full name' '\n> +\ttest refs/remotes/origin/master = \"$(full_name @{U})\"\n> +'\n> +\n> +test_expect_success '@{Upstream} resolves to correct full name' '\n> +\ttest refs/remotes/origin/master = \"$(full_name @{Upstream})\"\n> +'\n> +\n> test_expect_success 'my-side@{upstream} resolves to correct full name' '\n> \ttest refs/remotes/origin/side = \"$(full_name my-side@{u})\"\n> '\n\nEven though I sometimes use @{upstream} these days to keep track of\norigins of various topic branches (some are fixes and fork from maint\nwhile others are features and fork from master), I never felt a need for\n@{U} or @{uPStreAM} myself, so as a new feature, this change is a \"Meh\"\nfor me personally.\n\nCurrently, we use @{...} for:\n\n - Negative integers are \"-N branch-switching ago\" (only without any ref\n on the left);\n - Non-negative integers \"The tip of the named ref before it was changed N\n times\";\n - An approxidate that is case insensitive; or\n - \"u\" and \"upstream\".\n\nLetting u/upstream spelled case-insensitively does improve consistency\namong the above, but at the same time if we ever wanted to enhance @{...}\nnotation even further in the future, we are restricted to a payload that\nis case insensitive to retain the consistency.\n\nThe only remotely semi-plausible enhancement I could think of is perhaps\nto allow @{/regexp} to find a reflog entry that matches the given pattern,\nand in such a use case we would certainly want to take the pattern in a\ncase sensitive way. This change closes the door to that, and that is the\nonly downside I can think of right now.\n\nI hate to declare that we will never support such a feature with this\nchange, but at the same time, I do not think I would need such a feature\nthat often. But for that matter, I do not think I would miss @{UpStREAM},\neither, and that takes me back to \"Meh\" for this change.\n\nWhat do people think?\n"},{"id":"173710","messageId":"CACsJy8CX7X3u4i_kXChVHkFK=Q--pRBrxmdvjxrF7wr5_SyakA@mail.gmail.com","threadId":"28086","inReplyTo":"7vhb5fd4zy.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-08-18T01:53:29Z","receivedAt":"2011-08-18T01:53:29Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Aug 18, 2011 at 5:53 AM, Junio C Hamano wrote:\n> Letting u/upstream spelled case-insensitively does improve consistency\n> among the above, but at the same time if we ever wanted to enhance @{...}\n> notation even further in the future, we are restricted to a payload that\n> is case insensitive to retain the consistency.\n>\n> The only remotely semi-plausible enhancement I could think of is perhaps\n> to allow @{/regexp} to find a reflog entry that matches the given pattern,\n> and in such a use case we would certainly want to take the pattern in a\n> case sensitive way. This change closes the door to that, and that is the\n> only downside I can think of right now.\n>\n> I hate to declare that we will never support such a feature with this\n> change, but at the same time, I do not think I would need such a feature\n> that often. But for that matter, I do not think I would miss @{UpStREAM},\n> either, and that takes me back to \"Meh\" for this change.\n>\n> What do people think?\n\nThe itch is probably because people have to release shift, then press\nshift again to type \"@{u}\". How about allow case insensitive match if\nthere's only _one_ letter inside @{}?\n\nThat would solve the shift problem while leaving door for @{...} extension.\n-- \nDuy\n"},{"id":"173730","messageId":"4E4CBC29.7080703@drmicha.warpmail.net","threadId":"28086","inReplyTo":"CACsJy8CX7X3u4i_kXChVHkFK=Q--pRBrxmdvjxrF7wr5_SyakA@mail.gmail.com","subject":"Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-08-18T07:15:53Z","receivedAt":"2011-08-18T07:15:53Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nguyen Thai Ngoc Duy venit, vidit, dixit 18.08.2011 03:53:\n> On Thu, Aug 18, 2011 at 5:53 AM, Junio C Hamano wrote:\n>> Letting u/upstream spelled case-insensitively does improve consistency\n>> among the above, but at the same time if we ever wanted to enhance @{...}\n>> notation even further in the future, we are restricted to a payload that\n>> is case insensitive to retain the consistency.\n>>\n>> The only remotely semi-plausible enhancement I could think of is perhaps\n>> to allow @{/regexp} to find a reflog entry that matches the given pattern,\n>> and in such a use case we would certainly want to take the pattern in a\n>> case sensitive way. This change closes the door to that, and that is the\n>> only downside I can think of right now.\n>>\n>> I hate to declare that we will never support such a feature with this\n>> change, but at the same time, I do not think I would need such a feature\n>> that often. But for that matter, I do not think I would miss @{UpStREAM},\n>> either, and that takes me back to \"Meh\" for this change.\n>>\n>> What do people think?\n> \n> The itch is probably because people have to release shift, then press\n> shift again to type \"@{u}\". How about allow case insensitive match if\n> there's only _one_ letter inside @{}?\n> \n> That would solve the shift problem while leaving door for @{...} extension.\n\nWell, this patch is actually specific to a particular keyboard layout!\nIt improves things only for a layout where you get @ and { using a shift\nkey.\n\nFor a german keyboard layout, you get @{u} from\n\nhold AltGr (Meta)\npress q\npress 7\nrelease AltGr\npress u\nhold AltGr\npress 0\n\nFor me, an improvement would be to have the alias\n\n@{↓}\n\nfor @{u} so that I can hold AltGr throughout and press q7u0. Which would\nbe very nice, pictorially :)\n\nIn general git could benefit from a rev alias mechanism. This idea has\ncome up several times, but in order to be really useful, we would need\nthat to be more general than textual replacements and allow for macro\nlike replacements such as\n\ngit config revalias.new \"\\1@{1}..\\1\"\n\nto be used as, say\n\ngit log @{new(origin/next)}\n\nafter a fetch. (No, I'm not suggesting that specific syntax here.)\n\nAs a simpler case, a user could tailor to her keyboard layout with\n\ngit config revalias.↓ u\n\nbut for obvious reasons\n\ngit config revalias.U u\n\nwon't work.\n\nSo, maybe we could make the key part of a special revspec case\ninsensitive (just like config variable names) but still have a possible\npayload (parameter) be case sensitive (just like config variable values)?\n\nMichael\n"},{"id":"173741","messageId":"CACsJy8Dr5q=h-9MhNV0gKtVEn13+DxWwcNn2Prem6-+DyrDmHA@mail.gmail.com","threadId":"28086","inReplyTo":"4E4CBC29.7080703@drmicha.warpmail.net","subject":"Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-08-18T08:54:05Z","receivedAt":"2011-08-18T08:54:05Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Aug 18, 2011 at 2:15 PM, Michael J Gruber\n wrote:\n> For a german keyboard layout, you get @{u} from\n>\n> hold AltGr (Meta)\n> press q\n> press 7\n> release AltGr\n> press u\n> hold AltGr\n> press 0\n>\n> For me, an improvement would be to have the alias\n>\n> @{↓}\n\nWhile it's convenient to type, the output now looks strange. If you do\na screencast, or someone is watching you, they may not understand what\nthat syntax is.\n\nAlso..\n\n> As a simpler case, a user could tailor to her keyboard layout with\n>\n> git config revalias.↓ u\n\nWe may also have encoding issue here. What if config file is in utf-8,\nbut the console is not?\n\nSo I don't we should go this way. There may be a better way to deal\nwith different keyboard layouts.\n\n> Well, this patch is actually specific to a particular keyboard layout!\n> It improves things only for a layout where you get @ and { using a shift\n> key.\n\nFully agreed. While it does not help non en-US keyboards, it does not\ncause any harm (jealousy is not classified as harm to me, rather\nmotivation ;).\n-- \nDuy\n"},{"id":"173745","messageId":"4E4CDBF5.4040709@drmicha.warpmail.net","threadId":"28086","inReplyTo":"CACsJy8Dr5q=h-9MhNV0gKtVEn13+DxWwcNn2Prem6-+DyrDmHA@mail.gmail.com","subject":"Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-08-18T09:31:33Z","receivedAt":"2011-08-18T09:31:33Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nguyen Thai Ngoc Duy venit, vidit, dixit 18.08.2011 10:54:\n> On Thu, Aug 18, 2011 at 2:15 PM, Michael J Gruber\n> wrote:\n>> For a german keyboard layout, you get @{u} from\n>>\n>> hold AltGr (Meta)\n>> press q\n>> press 7\n>> release AltGr\n>> press u\n>> hold AltGr\n>> press 0\n>>\n>> For me, an improvement would be to have the alias\n>>\n>> @{↓}\n> \n> While it's convenient to type, the output now looks strange. If you do\n> a screencast, or someone is watching you, they may not understand what\n> that syntax is.\n\njust like with any shell or git alias.\n\n> \n> Also..\n> \n>> As a simpler case, a user could tailor to her keyboard layout with\n>>\n>> git config revalias.↓ u\n> \n> We may also have encoding issue here. What if config file is in utf-8,\n> but the console is not?\n\nIt's a user setting, tailored for the user's environment.\n\n> So I don't we should go this way. There may be a better way to deal\n> with different keyboard layouts.\n> \n>> Well, this patch is actually specific to a particular keyboard layout!\n>> It improves things only for a layout where you get @ and { using a shift\n>> key.\n> \n> Fully agreed. While it does not help non en-US keyboards, it does not\n> cause any harm (jealousy is not classified as harm to me, rather\n> motivation ;).\n\nIf you sell it as\n\n\"rev key is like a config key, so make it case insensitive. As a side\neffect, it helps certain keyboard layouts and does not harm others.\"\n\nit may fair a better chance ;)\n\nI guess this should apply to rev^{} as well, then.\n\nMichael\n"},{"id":"173875","messageId":"CAOTq_pvFLs+7QZ2CZT6TVw=m+UioKjtSkuPiBfAnCv=Mb1Q0PQ@mail.gmail.com","threadId":"28086","inReplyTo":"4E4CDBF5.4040709@drmicha.warpmail.net","subject":"Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}","fromName":"Conrad Irwin","fromEmail":"conrad.irwin@gmail.com","sentAt":"2011-08-19T18:54:57Z","receivedAt":"2011-08-19T18:54:57Z","isPatch":true,"sender":{"key":"conrad.irwin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94272?v=4"},"body":"On Wed, Aug 17, 2011 at 3:53 PM, Junio C Hamano wrote:\n> Currently, we use @{...} for:\n>\n>  - Negative integers are \"-N branch-switching ago\" (only without any ref\n>   on the left);\n>  - Non-negative integers \"The tip of the named ref before it was changed N\n>   times\";\n>  - An approxidate that is case insensitive; or\n>  - \"u\" and \"upstream\".\n[snip]\n> The only remotely semi-plausible enhancement I could think of is perhaps\n> to allow @{/regexp} to find a reflog entry that matches the given pattern,\n> and in such a use case we would certainly want to take the pattern in a\n> case sensitive way. This change closes the door to that, and that is the\n> only downside I can think of right now.\n\nI'm reasonably convinced by this argument as a refutation of the\nconsistency argument I proposed above. Given that the date format will\nalways be insensitive, and any enhancements added would probably want\nto be case-sensitive (I can think of a few other things I'd \"like\",\nbut which are pretty silly: @{merge-base *}, @{octopus-base\n*}); this syntax is always going to be inconsistent.\nAdditionally, as pointed out elsewhere in the thread, the most-similar\nexisting syntax (^{tree}) is already case-sensitive.\n\nGiven all of the above, I think that allowing @{upstream} to be\ncase-insensitive is certainly wrong, as it's slightly confusing and\nnot very useful.\n\nGiven that @{upstream} should be case-sensitive, it would be bizarre\nto allow @{U} as a synonym, so I think I'm convinced that this is not\nworth it, despite the convenience it brings.\n\nOn Thu, Aug 18, 2011 at 2:31 AM, Michael J Gruber\n wrote:\n>>> As a simpler case, a user could tailor to her keyboard layout with\n>>>\n>>> git config revalias.↓ u\n>>\n\nHmm, this opens up interesting ideas:\n\ngit config revalias.base = '! git merge-base -a \"$@\"'\ngit show HEAD@{base master}\n\nbut that seems like it's a bit over-the-top for some reason :).\n\nConrad\n"}]}