{"thread":{"id":"57424","subject":"[PATCH] branch: delete now accepts '-' as branch name","startedAt":"2022-02-16T14:08:21Z","lastAt":"2022-02-22T11:05:33Z","messageCount":11,"participants":["Erlend Egeberg Aasland via GitGitGadget","Junio C Hamano","Eric Sunshine","Erlend Aasland","Ævar Arnfjörð Bjarmason"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"448595","messageId":"pull.1217.git.git.1645020495014.gitgitgadget@gmail.com","threadId":"57424","inReplyTo":null,"subject":"[PATCH] branch: delete now accepts '-' as branch name","fromName":"Erlend Egeberg Aasland via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-02-16T14:08:14Z","receivedAt":"2022-02-16T14:08:21Z","isPatch":true,"sender":{"key":"name:Erlend Egeberg Aasland","avatar":null},"body":"From: \"Erlend E. Aasland\" \n\nThis makes it easy to get rid of short-lived branches:\n\n$ git switch -c experiment\n$ git switch -\n$ git branch -D -\n\n$ gh pr checkout nnn\n$ make && make test\n$ git switch -\n$ git branch -D -\n\nSigned-off-by: Erlend E. Aasland \n---\n [RFC] branch: delete now accepts '-' as branch name\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1217%2Ferlend-aasland%2Fbranch-name-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1217/erlend-aasland/branch-name-v1\nPull-Request: https://github.com/git/git/pull/1217\n\n builtin/branch.c | 6 +++++-\n t/t3200-branch.sh | 8 ++++++++\n 2 files changed, 13 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 4ce2a247542..f6c876c09d2 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -236,7 +236,11 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,\n \t\tchar *target = NULL;\n \t\tint flags = 0;\n \n-\t\tstrbuf_branchname(&bname, argv[i], allowed_interpret);\n+\t\tif (!strcmp(argv[i], \"-\")) {\n+\t\t\tstrbuf_branchname(&bname, \"@{-1}\", allowed_interpret);\n+\t\t} else {\n+\t\t\tstrbuf_branchname(&bname, argv[i], allowed_interpret);\n+\t\t}\n \t\tfree(name);\n \t\tname = mkpathdup(fmt, bname.buf);\n \ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\nindex 1bc3795847d..6afb7150534 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -71,6 +71,14 @@ test_expect_success 'git branch -d d/e/f should delete a branch and a log' '\n \ttest_must_fail git reflog exists refs/heads/d/e/f\n '\n \n+test_expect_success 'git branch -D - should delete branch @{-1}' '\n+\tgit switch -c j &&\n+\tgit switch - &&\n+\tgit branch -D - &&\n+\ttest_path_is_missing .git/refs/heads/j &&\n+\ttest_must_fail git reflog exists refs/heads/j\n+'\n+\n test_expect_success 'git branch j/k should work after branch j has been deleted' '\n \tgit branch j &&\n \tgit branch -d j &&\n\nbase-commit: b80121027d1247a0754b3cc46897fee75c050b44\n-- \ngitgitgadget\n"},{"id":"448615","messageId":"xmqqbkz6vjkj.fsf@gitster.g","threadId":"57424","inReplyTo":"pull.1217.git.git.1645020495014.gitgitgadget@gmail.com","subject":"Re: [PATCH] branch: delete now accepts '-' as branch name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-02-16T16:54:04Z","receivedAt":"2022-02-16T16:54:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"> From: \"Erlend E. Aasland\" \n>\n> This makes it easy to get rid of short-lived branches:\n>\n> $ git switch -c experiment\n> $ git switch -\n> $ git branch -D -\n\nOr you can use @{-1} directly. Or short-lived experiment can\ndirectly be done on HEAD without any branch ;-)\n\nIn any case, the above is sufficient demonstration. I do not think\nyou'd need a second one that is identical---having two may help you\ndemonstrate there are multiple ways to start a short-lived branch\nthat you want to get rid of quickly, but it does not help convince\nothers how useful \"branch -\" is in such situations.\n\n> $ gh pr checkout nnn\n> $ make && make test\n> $ git switch -\n> $ git branch -D -\n>\n> Signed-off-by: Erlend E. Aasland \n> ---\n\n\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> index 4ce2a247542..f6c876c09d2 100644\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -236,7 +236,11 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,\n> \t\tchar *target = NULL;\n> \t\tint flags = 0;\n> \n> -\t\tstrbuf_branchname(&bname, argv[i], allowed_interpret);\n> +\t\tif (!strcmp(argv[i], \"-\")) {\n> +\t\t\tstrbuf_branchname(&bname, \"@{-1}\", allowed_interpret);\n> +\t\t} else {\n> +\t\t\tstrbuf_branchname(&bname, argv[i], allowed_interpret);\n> +\t\t}\n> \t\tfree(name);\n> \t\tname = mkpathdup(fmt, bname.buf);\n\nYou do not need if/else here.\n\n+\tif (!strcmp(argv[i], \"-\"))\n+\t\targv[i] = \"@{-1}\";\n\tstrbuf_branchname(&bname, argv[i], allowed_interpret);\n\nshould be sufficient. If you want to avoid assigning to argv[i],\nif/else is OK, but then lose the unnecessary {pair of braces} around\nsingle-statement blocks.\n\n> +test_expect_success 'git branch -D - should delete branch @{-1}' '\n> +\tgit switch -c j &&\n> +\tgit switch - &&\n> +\tgit branch -D - &&\n> +\ttest_path_is_missing .git/refs/heads/j &&\n\nThese days we try hard *NOT* to assume how refs are stored in the\nsystem. Please don't peek into .git/ at filesystem level, when you\ncan achieve what you want to in some other way.\n\n test_must_fail git show-ref --verify refs/heads/j\n\nwould be a more direct way.\n\n> +\ttest_must_fail git reflog exists refs/heads/j\n\nWe should try not to assume that reflog for ref X is lost when ref X\nitself goes away in newer tests and update such assumptions in older\ntests. Ideally we would want to be able to say \"at time X, branch\n'j' was removed, and at time X+Y, branch 'j' was recreated\", and\nadding more of these will make such an improvement harder to make.\n\nThis script is riddled with instances of these existing problems.\nPlease don't make it even worse by adding on top of them.\n\nThe added ones is a positive test. A new feature works as expected\nin a situation where it should kick in. There needs an accompanying\nnegative test or two, making sure it fails sensibly in a situation\nwhere it should fail. Off the top of my head, negative tests that\nare appropriate for this new feature are:\n\n * In a freshly created repository, possibly creating a few\n commits on the initial branch without ever switching to a\n different branch, what should happen when you use the new\n \"branch -d -\" feature? What error message, if any, should\n the user see? Do we show that expected message?\n\n * Switch to a new branch, create a commit on top, switch back to\n the original branch and run \"branch -d -\". This should fail\n because you'd be losing the commit created on the branch.\n What error message should the user see? Do we show the name\n of the branch correctly? Do we show \"@{-1}\", or \"-\"?\n\n * After running \"branch -D -\" to successfully remove the\n previous branch, run \"branch -D -\" again. This should fail\n because the branch you are trying to remove no longer exists.\n What error message should the user see?\n\nThanks for trying to make Git better.\n\n"},{"id":"448629","messageId":"00720bfb-c7b7-aaf2-e846-19b08d7b9cf4@sunshineco.com","threadId":"57424","inReplyTo":"xmqqbkz6vjkj.fsf@gitster.g","subject":"Re: [PATCH] branch: delete now accepts '-' as branch name","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2022-02-16T19:03:38Z","receivedAt":"2022-02-16T19:03:43Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On 2/16/22 11:54 AM, Junio C Hamano wrote:\n> From: \"Erlend E. Aasland\" \n>> This makes it easy to get rid of short-lived branches:\n>>\n>> $ git switch -c experiment\n>> $ git switch -\n>> $ git branch -D -\n> \n> Or you can use @{-1} directly. Or short-lived experiment can\n> directly be done on HEAD without any branch ;-)\n> \n> Thanks for trying to make Git better.\n\nPatches implementing this behavior for `git branch -D` have been \nsubmitted previously but were rejected (if I recall correctly) since \n\"delete\" is a destructive operation, unlike other cases in which `-` is \naccepted. A relatively recent submission and ensuing discussion is at [1].\n\n[1]: https://lore.kernel.org/git/20200501222227.GE41612@syl.local/T/\n"},{"id":"448630","messageId":"xmqqv8xed2f3.fsf@gitster.g","threadId":"57424","inReplyTo":"00720bfb-c7b7-aaf2-e846-19b08d7b9cf4@sunshineco.com","subject":"Re: [PATCH] branch: delete now accepts '-' as branch name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-02-16T19:41:52Z","receivedAt":"2022-02-16T19:42:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> On 2/16/22 11:54 AM, Junio C Hamano wrote:\n>> From: \"Erlend E. Aasland\" \n>>> This makes it easy to get rid of short-lived branches:\n>>>\n>>> $ git switch -c experiment\n>>> $ git switch -\n>>> $ git branch -D -\n>> Or you can use @{-1} directly. Or short-lived experiment can\n>> directly be done on HEAD without any branch ;-)\n>> Thanks for trying to make Git better.\n>\n> Patches implementing this behavior for `git branch -D` have been\n> submitted previously but were rejected (if I recall correctly) since \n> \"delete\" is a destructive operation, unlike other cases in which `-`\n> is accepted. A relatively recent submission and ensuing discussion is\n> at [1].\n>\n> [1]: https://lore.kernel.org/git/20200501222227.GE41612@syl.local/T/\n\nI think the thread around is what you\nhave in mind as the origin of\n\n * \"-\" usually stands for \"read from standard input\" and using it to\n mean \"the previous branch\" is a source of confusion, and cannot\n be defended with the excuse of \"'cd -' is used to go back to\n where we were\" when the command is not going back to that branch\n (i.e. not \"checkout -\" or \"switch -\").\n\n * it is doubly dubious to make it easy to type \"-\" to cause\n something destructive.\n\n * on the other hand, since \"checkout -\" already makes \"-\" as a\n synonym to \"@{-1}\", not supporting it elsewhere may appear\n inconsistent.\n\nI personally am sympathetic to the first point, but not that\nsympathetic to the second one. We made it worse since then by\naccepting \"merge -\", which is not about going back, though.\n\n"},{"id":"448645","messageId":"400A4D37-74EA-4F3B-BA3B-99FFDAE3CB3C@innova.no","threadId":"57424","inReplyTo":"00720bfb-c7b7-aaf2-e846-19b08d7b9cf4@sunshineco.com","subject":"Re: [PATCH] branch: delete now accepts '-' as branch name","fromName":"Erlend Aasland","fromEmail":"erlend-a@innova.no","sentAt":"2022-02-16T23:06:34Z","receivedAt":"2022-02-16T23:06:44Z","isPatch":true,"sender":{"key":"erlend-a@innova.no","avatar":null},"body":"\n> On 16 Feb 2022, at 20:03, Eric Sunshine wrote:\n> \n> Patches implementing this behavior for `git branch -D` have been submitted previously but were rejected (if I recall correctly) since \"delete\" is a destructive operation, unlike other cases in which `-` is accepted. A relatively recent submission and ensuing discussion is at [1].\n> \n> [1]: https://lore.kernel.org/git/20200501222227.GE41612@syl.local/T/\n\nThanks for the heads-up regarding previous discussions, Eric.\n\nAFAIK, switch/checkout, rebase, and merge all use \"-\" as a shortcut to the\n\"last branch\", so for me, it made sense with similar semantics when deleting a\nbranch. I understand the concern regarding \"destructive operations\", but\ndeleting a branch is not comparable to, for example, deleting a file. Deleting\na branch is \"soft destructive\"; unless *explicitly* silenced, git kindly tells\nus which ref we can use to immediately recreate our branch:\n\n$ git branch -D - # oops, shouldn't have done that!\nDeleted branch stuff (was 580cd9ab29).\n$ git switch -c stuff 580cd9ab29\n\nUntil now, I've just been using the @{-1} notation, but - is very much faster\nto type ;)\n\nThere are no new arguments pro this feature, so I guess the conclusion from\n2020 still stands :)\n\n\nE\n"},{"id":"448718","messageId":"CAPig+cR0Ks2bnTRqs3uF4M+3q+n9X6pApBQ9HQTUq=zK5TpuXQ@mail.gmail.com","threadId":"57424","inReplyTo":"400A4D37-74EA-4F3B-BA3B-99FFDAE3CB3C@innova.no","subject":"Re: [PATCH] branch: delete now accepts '-' as branch name","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2022-02-17T17:13:10Z","receivedAt":"2022-02-17T17:13:25Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Feb 17, 2022 at 7:51 AM Erlend Aasland wrote:\n> > On 16 Feb 2022, at 20:03, Eric Sunshine wrote:\n> > Patches implementing this behavior for `git branch -D` have been submitted previously but were rejected (if I recall correctly) since \"delete\" is a destructive operation, unlike other cases in which `-` is accepted. A relatively recent submission and ensuing discussion is at [1].\n> >\n> > [1]: https://lore.kernel.org/git/20200501222227.GE41612@syl.local/T/\n>\n> Thanks for the heads-up regarding previous discussions, Eric.\n>\n> Until now, I've just been using the @{-1} notation, but - is very much faster\n> to type ;)\n>\n> There are no new arguments pro this feature, so I guess the conclusion from\n> 2020 still stands :)\n\nPerhaps. Perhaps not. I may be misreading Junio's responses in this\nthread, but it didn't seem like he was necessarily opposed to the\nchange. A documentation update as in [1] would be a good idea, though,\nif resubmitted.\n"},{"id":"448725","messageId":"xmqqiltd9vyg.fsf@gitster.g","threadId":"57424","inReplyTo":"CAPig+cR0Ks2bnTRqs3uF4M+3q+n9X6pApBQ9HQTUq=zK5TpuXQ@mail.gmail.com","subject":"Re: [PATCH] branch: delete now accepts '-' as branch name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-02-17T18:41:59Z","receivedAt":"2022-02-17T18:42:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> Perhaps. Perhaps not. I may be misreading Junio's responses in this\n> thread, but it didn't seem like he was necessarily opposed to the\n> change.\n\nI do not care too much about this issue to expend my political\ncapital on enforcing my preference ;-)\n\nFWIW, my preference in an ideal world would be to limit \"-\" as a\nshort-hand to go back to previous (i.e. \"checkout -\"), which can be\njustified with similarity to \"cd -\", but do not add any more use.\nIf we could, I would even deprecate \"merge -\", \"rebase -\", etc. that\ncan not be justified with similarity to \"cd -\", but I think we came\ntoo far for that.\n\n\"-\" cannot be used as a universal \"the branch we last 'git checkout'\nout of\" notation because some commands and people expect \"-\" to be\nsomething else, like \"read from the standard input\". The only two\nreasons this pops up from time to time is because \"checkout -\"\nexists and because \"@{-N}\" notation, which is accepted everywhere\nuniformly and does not have problems \"-\" has, is not very well\nknown.\n\n> A documentation update as in [1] would be a good idea, though,\n> if resubmitted.\n\nYeah, [1] talked about both \"@{-1}\" and \"-\", but limiting it to the\nformer may make sense. It feels a bit odd that we single out \"git\nbranch\" and describe \"@{-1}\" there, when the notation is universally\navailable, though.\n\n $ git grep -l '@{-' -- Documentation/ :\\!Documentation/\\*/\\*\n\nshows hits only in check-ref-format, checkout, switch, and worktree,\nbut the mention in \"revisions.txt\" is included in all commands in\nthe \"log\" family of commands. If we add one to \"branch\", we should\nat least teach \"@{-1}\" to the documentation of merge, rebase, and\nrevert. The hits we see here\n\n $ git grep -l -B1 '\"@{-' \\*.c\n builtin/checkout.c\n builtin/merge.c\n builtin/rebase.c\n builtin/revert.c\n builtin/worktree.c\n\nall are about replacing \"-\" the user typed with \"@{-1}\".\n\nContinuing the \"thinking aloud\" a bit, I _think_ this tells us these\nthings:\n\n * @{-1} has way too many letters to type to be liked by users, who\n won't learn or remember what they do not appreciate (and do not\n blame them---it is a bad notation).\n\n * @{-} may have been a generalized way that satisfied geeky mind\n while being implemented, but the users only need the \"last one\"\n and no such generalization.\n\nIf it is too late for a more easy-to-type-and-pleasant-to-eyes\nnotation, perhaps \"@-\", that does not have downsides of \"-\" or\n\"@{-1}\", I have to wonder.\n\nThanks.\n\n"},{"id":"449018","messageId":"220221.86pmngb22e.gmgdl@evledraar.gmail.com","threadId":"57424","inReplyTo":"xmqqiltd9vyg.fsf@gitster.g","subject":"Re: [PATCH] branch: delete now accepts '-' as branch name","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-02-21T16:34:01Z","receivedAt":"2022-02-21T16:46:22Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Feb 17 2022, Junio C Hamano wrote:\n\n> Eric Sunshine writes:\n>\n>> Perhaps. Perhaps not. I may be misreading Junio's responses in this\n>> thread, but it didn't seem like he was necessarily opposed to the\n>> change.\n>\n> I do not care too much about this issue to expend my political\n> capital on enforcing my preference ;-)\n>\n> FWIW, my preference in an ideal world would be to limit \"-\" as a\n> short-hand to go back to previous (i.e. \"checkout -\"), which can be\n> justified with similarity to \"cd -\", but do not add any more use.\n> If we could, I would even deprecate \"merge -\", \"rebase -\", etc. that\n> can not be justified with similarity to \"cd -\", but I think we came\n> too far for that.\n>\n> \"-\" cannot be used as a universal \"the branch we last 'git checkout'\n> out of\" notation because some commands and people expect \"-\" to be\n> something else, like \"read from the standard input\". The only two\n> reasons this pops up from time to time is because \"checkout -\"\n> exists and because \"@{-N}\" notation, which is accepted everywhere\n> uniformly and does not have problems \"-\" has, is not very well\n> known.\n>\n>> A documentation update as in [1] would be a good idea, though,\n>> if resubmitted.\n>\n> Yeah, [1] talked about both \"@{-1}\" and \"-\", but limiting it to the\n> former may make sense. It feels a bit odd that we single out \"git\n> branch\" and describe \"@{-1}\" there, when the notation is universally\n> available, though.\n>\n> $ git grep -l '@{-' -- Documentation/ :\\!Documentation/\\*/\\*\n>\n> shows hits only in check-ref-format, checkout, switch, and worktree,\n> but the mention in \"revisions.txt\" is included in all commands in\n> the \"log\" family of commands. If we add one to \"branch\", we should\n> at least teach \"@{-1}\" to the documentation of merge, rebase, and\n> revert. The hits we see here\n>\n> $ git grep -l -B1 '\"@{-' \\*.c\n> builtin/checkout.c\n> builtin/merge.c\n> builtin/rebase.c\n> builtin/revert.c\n> builtin/worktree.c\n>\n> all are about replacing \"-\" the user typed with \"@{-1}\".\n>\n> Continuing the \"thinking aloud\" a bit, I _think_ this tells us these\n> things:\n>\n> * @{-1} has way too many letters to type to be liked by users, who\n> won't learn or remember what they do not appreciate (and do not\n> blame them---it is a bad notation).\n>\n> * @{-} may have been a generalized way that satisfied geeky mind\n> while being implemented, but the users only need the \"last one\"\n> and no such generalization.\n>\n> If it is too late for a more easy-to-type-and-pleasant-to-eyes\n> notation, perhaps \"@-\", that does not have downsides of \"-\" or\n> \"@{-1}\", I have to wonder.\n\nI too find the syntax really annoying to type.\n\nI wonder if we couldn't say that:\n\n * @[-]N is the same as @{[-]N}. I.e. @1 is the same as @{1} and @{-1}\n is the same as @-1\n\n * Optionally (and this is a bit nasty) say that @{-} is a synonym for\n @{-1}, and therefore @- is the same as @-1 is the same as @{-1}.\n\n Nasty because the logical conclusion would be that @ is the same as\n @1, but it's HEAD, but this would allow us to have a shorter \"@-\" for\n \"delete last\", as opposed to \"@-1\". Also @{-0} (which would presumably\n be a synonym for \"HEAD\", or \"@\" errors out currently, and would continue\n to do so).\n\n * Declare that any other single-letter special @{...} syntax is the\n same as @...; In particular that @u would be @{u} which is short for\n @{upstream}.\n\n * Live more dangerously and allow @push @upstream etc.? One the one\n hand it feels a bit usurp-y to close the door on such a syntax having\n a similar meaning as regex flags where /ix is /i and /x, but on the\n other hand I don't really see us wanting @pu for \"@push\" and\n \"@upstream\" at the same time (makes no sense...).\n\nI haven't hacked it up (and won't any time soon), Erlend: are you\ninterested? :)\n"},{"id":"449019","messageId":"xmqqwnhota5q.fsf@gitster.g","threadId":"57424","inReplyTo":"220221.86pmngb22e.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH] branch: delete now accepts '-' as branch name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-02-21T17:13:53Z","receivedAt":"2022-02-21T17:14:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n>> Continuing the \"thinking aloud\" a bit, I _think_ this tells us these\n>> things:\n>>\n>> * @{-1} has way too many letters to type to be liked by users, who\n>> won't learn or remember what they do not appreciate (and do not\n>> blame them---it is a bad notation).\n>>\n>> * @{-} may have been a generalized way that satisfied geeky mind\n>> while being implemented, but the users only need the \"last one\"\n>> and no such generalization.\n>>\n>> If it is too late for a more easy-to-type-and-pleasant-to-eyes\n>> notation, perhaps \"@-\", that does not have downsides of \"-\" or\n>> \"@{-1}\", I have to wonder.\n>\n> I too find the syntax really annoying to type.\n>\n> I wonder if we couldn't say that:\n> ...\n\nWe could, but I do not think I like any of it, except for adding\n\"@-\". We learned that we do not need @{-4} generalization and\npeople only want \"the last one\" with nothing else. It is repeating\nthe same mistake without learning any from the lesson to take any\nrandom string that follows @ as if it is inside @{}, I am afraid.\n\nP.S. It seems it is holiday around here and I hear it is at GitHub,\ntoo, so I expect the day to be slow and my presence may be sporadic.\n\n\n\n"},{"id":"449043","messageId":"220221.86zgmk9g68.gmgdl@evledraar.gmail.com","threadId":"57424","inReplyTo":"xmqqwnhota5q.fsf@gitster.g","subject":"Re: [PATCH] branch: delete now accepts '-' as branch name","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-02-21T19:20:22Z","receivedAt":"2022-02-21T19:24:25Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Feb 21 2022, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason writes:\n>\n>>> Continuing the \"thinking aloud\" a bit, I _think_ this tells us these\n>>> things:\n>>>\n>>> * @{-1} has way too many letters to type to be liked by users, who\n>>> won't learn or remember what they do not appreciate (and do not\n>>> blame them---it is a bad notation).\n>>>\n>>> * @{-} may have been a generalized way that satisfied geeky mind\n>>> while being implemented, but the users only need the \"last one\"\n>>> and no such generalization.\n>>>\n>>> If it is too late for a more easy-to-type-and-pleasant-to-eyes\n>>> notation, perhaps \"@-\", that does not have downsides of \"-\" or\n>>> \"@{-1}\", I have to wonder.\n>>\n>> I too find the syntax really annoying to type.\n>>\n>> I wonder if we couldn't say that:\n>> ...\n>\n> We could, but I do not think I like any of it, except for adding\n> \"@-\". We learned that we do not need @{-4} generalization and\n> people only want \"the last one\" with nothing else.\n\nFWIW I often use @{-2}, @{-3} or equivalent, but never @{-28} or\nwhatever.\n\nNot often.\n\nBut I would very much appreciate @u if it existed. I use @{u} a lot, and\nwith the shift-key dancing it's a hassle to typ it.\n\n> the same mistake without learning any from the lesson to take any\n> random string that follows @ as if it is inside @{}, I am afraid.\n\nI think we should be careful to squat on namespaces needlessly, but if\nwe can't think of a reason for why we wouldn't make typing some of these\nshortcuts easier...\n\nIOW can we think of a reason we'd ever use @1 @-1 or @u for anything\nelse? It would be *very* confusing to add a new @{u} that behaved\ndifferently from @u, whatever such a @u would mean.\n\n> P.S. It seems it is holiday around here and I hear it is at GitHub,\n> too, so I expect the day to be slow and my presence may be sporadic.\n\n*nod*\n"},{"id":"449107","messageId":"EA5CFD34-9BFF-4030-9188-37953D947437@innova.no","threadId":"57424","inReplyTo":"220221.86zgmk9g68.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH] branch: delete now accepts '-' as branch name","fromName":"Erlend Aasland","fromEmail":"erlend-a@innova.no","sentAt":"2022-02-22T11:05:23Z","receivedAt":"2022-02-22T11:05:33Z","isPatch":true,"sender":{"key":"erlend-a@innova.no","avatar":null},"body":"\n> On 21 Feb 2022, at 20:20, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Mon, Feb 21 2022, Junio C Hamano wrote:\n> \n>> Ævar Arnfjörð Bjarmason writes:\n>> \n>>>> Continuing the \"thinking aloud\" a bit, I _think_ this tells us these\n>>>> things:\n>>>> \n>>>> * @{-1} has way too many letters to type to be liked by users, who\n>>>> won't learn or remember what they do not appreciate (and do not\n>>>> blame them---it is a bad notation).\n\n+1\n\n>>>> * @{-} may have been a generalized way that satisfied geeky mind\n>>>> while being implemented, but the users only need the \"last one\"\n>>>> and no such generalization.\n\nThat harmonises with my usage.\n\n> FWIW I often use @{-2}, @{-3} or equivalent, but never @{-28} or\n> whatever.\n\nDitto; I mostly (at least 95% of the time) only use @{-1}. I've used other\nsmall indices sporadically, but never a two-digit index.\n\n> I think we should be careful to squat on namespaces needlessly, but if\n> we can't think of a reason for why we wouldn't make typing some of these\n> shortcuts easier...\n\nIMO, it's not a shortcut if it's a hassle to type ;)\n\n\nIIRC, the GitHub \"Git Highlights\" Blog has promoted the '-' trick every now and then.\n\n\n> I haven't hacked it up (and won't any time soon), Erlend: are you interested? :)\n\nThere's a lot of suggestions floating around now, but sure, I'd be happy to give one of\nthem a go; at least as a proof-of-concept :)\n\n\n\nErlend"}]}