{"thread":{"id":"47506","subject":"[PATCH] Add shell completion for git remote rm","startedAt":"2017-12-29T02:01:31Z","lastAt":"2018-07-16T13:21:08Z","messageCount":23,"participants":["Keith Smiley","Todd Zullinger","Kevin Daudt","SZEDER Gábor","Ævar Arnfjörð Bjarmason","Duy Nguyen","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"335511","messageId":"01020160a0004473-277c3d7c-4e3b-4c50-9d44-4a106f37f1d9-000000@eu-west-1.amazonses.com","threadId":"47506","inReplyTo":null,"subject":"[PATCH] Add shell completion for git remote rm","fromName":"Keith Smiley","fromEmail":"k@keith.so","sentAt":"2017-12-29T02:01:00Z","receivedAt":"2017-12-29T02:01:31Z","isPatch":true,"sender":{"key":"k@keith.so","avatar":null},"body":"From: Keith Smiley \n\nPreviously git remote rm did not complete your list of removes as remove\ndoes.\n---\n contrib/completion/git-completion.bash | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 3683c772c5586..3e9044087e6ba 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -2665,7 +2665,7 @@ _git_config ()\n _git_remote ()\n {\n \tlocal subcommands=\"\n-\t\tadd rename remove set-head set-branches\n+\t\tadd rename remove rm set-head set-branches\n \t\tget-url set-url show prune update\n \t\t\"\n \tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n\n--\nhttps://github.com/git/git/pull/448\n"},{"id":"335513","messageId":"20171229032927.GN3693@zaya.teonanacatl.net","threadId":"47506","inReplyTo":"01020160a0004473-277c3d7c-4e3b-4c50-9d44-4a106f37f1d9-000000@eu-west-1.amazonses.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2017-12-29T03:29:28Z","receivedAt":"2017-12-29T03:29:40Z","isPatch":true,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"Hi Keith,\n\nKeith Smiley wrote:\n> Previously git remote rm did not complete your list of removes as remove\n> does.\n\nLooking through the history, the rm subcomand completion was\nexplicitly removed in e17dba8fe1 (\"remote: prefer subcommand\nname 'remove' to 'rm'\", 2012-09-06).\n\n-- \nTodd\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nGenius is 1% inspiration and 99% perspiration, which is why engineers\nsometimes smell really bad.\n -- Demotivators (www.despair.com)\n\n"},{"id":"335514","messageId":"20171229041927.GA83931@bryant.local","threadId":"47506","inReplyTo":"20171229032927.GN3693@zaya.teonanacatl.net","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Keith Smiley","fromEmail":"k@keith.so","sentAt":"2017-12-29T04:19:27Z","receivedAt":"2017-12-29T04:28:02Z","isPatch":true,"sender":{"key":"k@keith.so","avatar":null},"body":"It looks like that was just about preferring remove in documentation and \nthe like, I think it would still make sense to have both for completion \nsince rm is still supported.\n\n--\nKeith Smiley\n\nOn 12/28, Todd Zullinger wrote:\n>Hi Keith,\n>\n>Keith Smiley wrote:\n>> Previously git remote rm did not complete your list of removes as remove\n>> does.\n>\n>Looking through the history, the rm subcomand completion was\n>explicitly removed in e17dba8fe1 (\"remote: prefer subcommand\n>name 'remove' to 'rm'\", 2012-09-06).\n>\n>-- \n>Todd\n>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n>Genius is 1% inspiration and 99% perspiration, which is why engineers\n>sometimes smell really bad.\n> -- Demotivators (www.despair.com)\n>\n"},{"id":"335517","messageId":"20171229060016.GA25718@alpha.vpn.ikke.info","threadId":"47506","inReplyTo":"01020160a0004473-277c3d7c-4e3b-4c50-9d44-4a106f37f1d9-000000@eu-west-1.amazonses.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2017-12-29T06:00:16Z","receivedAt":"2017-12-29T06:00:26Z","isPatch":true,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Fri, Dec 29, 2017 at 02:01:00AM +0000, Keith Smiley wrote:\n> From: Keith Smiley \n> \n> Previously git remote rm did not complete your list of removes as remove\n> does.\n\nYour signed-off-by[1] is missing, could you please add that?\n\n[1]:\nhttps://github.com/git/git/blob/master/Documentation/SubmittingPatches#L278\n\n> ---\n> contrib/completion/git-completion.bash | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index 3683c772c5586..3e9044087e6ba 100644\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -2665,7 +2665,7 @@ _git_config ()\n> _git_remote ()\n> {\n> \tlocal subcommands=\"\n> -\t\tadd rename remove set-head set-branches\n> +\t\tadd rename remove rm set-head set-branches\n> \t\tget-url set-url show prune update\n> \t\t\"\n> \tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n> \n> --\n> https://github.com/git/git/pull/448\n"},{"id":"335518","messageId":"20171229062103.GA19203@bryant.local","threadId":"47506","inReplyTo":"20171229060016.GA25718@alpha.vpn.ikke.info","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Keith Smiley","fromEmail":"k@keith.so","sentAt":"2017-12-29T06:21:03Z","receivedAt":"2017-12-29T06:21:10Z","isPatch":true,"sender":{"key":"k@keith.so","avatar":null},"body":"Sorry about that! Patch below.\n\n\nPreviously git remote rm did not complete your list of removes as remove\ndoes.\n\nSigned-off-by: Keith Smiley \n---\n contrib/completion/git-completion.bash | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 3683c772c5586..3e9044087e6ba 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -2665,7 +2665,7 @@ _git_config ()\n _git_remote ()\n {\n \tlocal subcommands=\"\n-\t\tadd rename remove set-head set-branches\n+\t\tadd rename remove rm set-head set-branches\n \t\tget-url set-url show prune update\n \t\t\"\n \tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n\n--\nKeith Smiley\n\nOn 12/29, Kevin Daudt wrote:\n>On Fri, Dec 29, 2017 at 02:01:00AM +0000, Keith Smiley wrote:\n>> From: Keith Smiley \n>>\n>> Previously git remote rm did not complete your list of removes as remove\n>> does.\n>\n>Your signed-off-by[1] is missing, could you please add that?\n>\n>[1]:\n>https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L278\n>\n>> ---\n>> contrib/completion/git-completion.bash | 2 +-\n>> 1 file changed, 1 insertion(+), 1 deletion(-)\n>>\n>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n>> index 3683c772c5586..3e9044087e6ba 100644\n>> --- a/contrib/completion/git-completion.bash\n>> +++ b/contrib/completion/git-completion.bash\n>> @@ -2665,7 +2665,7 @@ _git_config ()\n>> _git_remote ()\n>> {\n>> \tlocal subcommands=\"\n>> -\t\tadd rename remove set-head set-branches\n>> +\t\tadd rename remove rm set-head set-branches\n>> \t\tget-url set-url show prune update\n>> \t\t\"\n>> \tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n>>\n>> --\n>> https://github.com/git/git/pull/448\n"},{"id":"335527","messageId":"20171229135240.GQ3693@zaya.teonanacatl.net","threadId":"47506","inReplyTo":"20171229041927.GA83931@bryant.local","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2017-12-29T13:52:40Z","receivedAt":"2017-12-29T13:52:50Z","isPatch":true,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"Keith Smiley wrote:\n> It looks like that was just about preferring remove in documentation\n> and the like, I think it would still make sense to have both for\n> completion since rm is still supported.\n\nI read it as a first step in a long process to eventually\nremove 'remote rm', but if that's never intended, then sure,\nrestoring completion for it seems reasonable.\n\nIt would be good to hear from those who know or recall the\nintention.\n\nI think we should only complete the preferred subcommand.\nThat encourages use of 'remote remove' even if 'remote rm'\nwill stay forever to avoid breaking existing scripts.\n\nIf it does make sense to restore completion, adding a link\nback to e17dba8fe1 and explaining why the completion is\nbeing restored would be good. Reading the commit message\nnow makes it sound like 'remote rm' was never present and is\nbeing added to correct an oversight.\n\nMaybe something like:\n\n completion: restore 'remote rm'\n\n e17dba8fe1 (\"remote: prefer subcommand name 'remove' to\n 'rm'\", 2012-09-06) removed the 'rm' subcommand from\n completion. The 'remote rm' subcommand is still supported\n and not planned to be removed. Offer completions for it.\n\nI also noticed that in your original commit that you say\n\"list of removes as remove does.\" That should be \"remotes\"\ninstead of \"removes\" there. -- I've made that typo myself\nquite often. :)\n\n-- \nTodd\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nThere are no stupid questions, but there are a LOT of inquisitive\nidiots.\n -- Demotivators (www.despair.com)\n\n"},{"id":"335539","messageId":"20171229164949.GA48812@bryant.local","threadId":"47506","inReplyTo":"20171229135240.GQ3693@zaya.teonanacatl.net","subject":"Re: [PATCH] completion: restore 'remote rm'","fromName":"Keith Smiley","fromEmail":"k@keith.so","sentAt":"2017-12-29T16:49:49Z","receivedAt":"2017-12-29T16:49:57Z","isPatch":true,"sender":{"key":"k@keith.so","avatar":null},"body":"Updated:\n\ne17dba8fe1 (\"remote: prefer subcommand name 'remove' to\n'rm'\", 2012-09-06) removed the 'rm' subcommand from\ncompletion. The 'remote rm' subcommand is still supported\nand not planned to be removed. Offer completions for it.\n\nSigned-off-by: Keith Smiley \n---\n contrib/completion/git-completion.bash | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 3683c772c5586..3e9044087e6ba 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -2665,7 +2665,7 @@ _git_config ()\n _git_remote ()\n {\n \tlocal subcommands=\"\n-\t\tadd rename remove set-head set-branches\n+\t\tadd rename remove rm set-head set-branches\n \t\tget-url set-url show prune update\n \t\t\"\n \tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n\n--\nKeith Smiley\n\nOn 12/29, Todd Zullinger wrote:\n>Keith Smiley wrote:\n>> It looks like that was just about preferring remove in documentation\n>> and the like, I think it would still make sense to have both for\n>> completion since rm is still supported.\n>\n>I read it as a first step in a long process to eventually\n>remove 'remote rm', but if that's never intended, then sure,\n>restoring completion for it seems reasonable.\n>\n>It would be good to hear from those who know or recall the\n>intention.\n>\n>I think we should only complete the preferred subcommand.\n>That encourages use of 'remote remove' even if 'remote rm'\n>will stay forever to avoid breaking existing scripts.\n>\n>If it does make sense to restore completion, adding a link\n>back to e17dba8fe1 and explaining why the completion is\n>being restored would be good. Reading the commit message\n>now makes it sound like 'remote rm' was never present and is\n>being added to correct an oversight.\n>\n>Maybe something like:\n>\n> completion: restore 'remote rm'\n>\n> e17dba8fe1 (\"remote: prefer subcommand name 'remove' to\n> 'rm'\", 2012-09-06) removed the 'rm' subcommand from\n> completion. The 'remote rm' subcommand is still supported\n> and not planned to be removed. Offer completions for it.\n>\n>I also noticed that in your original commit that you say\n>\"list of removes as remove does.\" That should be \"remotes\"\n>instead of \"removes\" there. -- I've made that typo myself\n>quite often. :)\n>\n>-- \n>Todd\n>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n>There are no stupid questions, but there are a LOT of inquisitive\n>idiots.\n> -- Demotivators (www.despair.com)\n>\n"},{"id":"335547","messageId":"20171229224825.31062-1-szeder.dev@gmail.com","threadId":"47506","inReplyTo":"20171229135240.GQ3693@zaya.teonanacatl.net","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-12-29T22:48:25Z","receivedAt":"2017-12-29T22:48:45Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"> Keith Smiley wrote:\n> > It looks like that was just about preferring remove in documentation\n> > and the like, I think it would still make sense to have both for\n> > completion since rm is still supported.\n> \n> I read it as a first step in a long process to eventually\n> remove 'remote rm', but if that's never intended, then sure,\n> restoring completion for it seems reasonable.\n> \n> It would be good to hear from those who know or recall the\n> intention.\n> \n> I think we should only complete the preferred subcommand.\n> That encourages use of 'remote remove' even if 'remote rm'\n> will stay forever to avoid breaking existing scripts.\n\nQuoting from the commit message of e17dba8fe1 (\"remote: prefer\nsubcommand name 'remove' to 'rm'\", 2012-09-06):\n\n 'rm' is still supported and used in the test suite. It's just not\n widely advertised.\n\nI think adding 'rm' to completion definitely counts as advertisement.\nIt doesn't have much practical use, after all: typing 'rm' with\ncompletion is actually one more keystroke than without (rm vs. rm).\n\n\nGábor\n\n"},{"id":"335551","messageId":"20171229231947.GA7698@bryant.local","threadId":"47506","inReplyTo":"20171229224825.31062-1-szeder.dev@gmail.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Keith Smiley","fromEmail":"k@keith.so","sentAt":"2017-12-29T23:19:47Z","receivedAt":"2017-12-29T23:19:53Z","isPatch":true,"sender":{"key":"k@keith.so","avatar":null},"body":"The goal of this fix isn't to complete rm itself (although that is a \nside effect), it's to complete the remote names after you type rm.\n\nWithout this patch doing this:\n\ngit remote rm \n\nAttempts to complete the options for `git remote` instead of the remote \nnames.\n\n--\nKeith Smiley\n\nOn 12/29, SZEDER Gábor wrote:\n>> Keith Smiley wrote:\n>> > It looks like that was just about preferring remove in documentation\n>> > and the like, I think it would still make sense to have both for\n>> > completion since rm is still supported.\n>>\n>> I read it as a first step in a long process to eventually\n>> remove 'remote rm', but if that's never intended, then sure,\n>> restoring completion for it seems reasonable.\n>>\n>> It would be good to hear from those who know or recall the\n>> intention.\n>>\n>> I think we should only complete the preferred subcommand.\n>> That encourages use of 'remote remove' even if 'remote rm'\n>> will stay forever to avoid breaking existing scripts.\n>\n>Quoting from the commit message of e17dba8fe1 (\"remote: prefer\n>subcommand name 'remove' to 'rm'\", 2012-09-06):\n>\n> 'rm' is still supported and used in the test suite. It's just not\n> widely advertised.\n>\n>I think adding 'rm' to completion definitely counts as advertisement.\n>It doesn't have much practical use, after all: typing 'rm' with\n>completion is actually one more keystroke than without (rm vs. rm).\n>\n>\n>Gábor\n>\n"},{"id":"335552","messageId":"87y3ll6s0e.fsf@evledraar.gmail.com","threadId":"47506","inReplyTo":"20171229224825.31062-1-szeder.dev@gmail.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-12-29T23:20:17Z","receivedAt":"2017-12-29T23:20:25Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Dec 29 2017, SZEDER Gábor jotted:\n\n>> Keith Smiley wrote:\n>> > It looks like that was just about preferring remove in documentation\n>> > and the like, I think it would still make sense to have both for\n>> > completion since rm is still supported.\n>>\n>> I read it as a first step in a long process to eventually\n>> remove 'remote rm', but if that's never intended, then sure,\n>> restoring completion for it seems reasonable.\n>>\n>> It would be good to hear from those who know or recall the\n>> intention.\n>>\n>> I think we should only complete the preferred subcommand.\n>> That encourages use of 'remote remove' even if 'remote rm'\n>> will stay forever to avoid breaking existing scripts.\n>\n> Quoting from the commit message of e17dba8fe1 (\"remote: prefer\n> subcommand name 'remove' to 'rm'\", 2012-09-06):\n>\n> 'rm' is still supported and used in the test suite. It's just not\n> widely advertised.\n\nI think we made the wrong choice in standardizing on remove instead of\nrm, it should be rm for consistency with git-rm, and \"remote rename\"\nshould be \"remote mv\" etc., just like we have git-mv.\n\nMaybe if we didn't have the Unix legacy we'd pick rename and remove to\nbe consitent for both, but since that's not going to happen this bit of\ninconsistency is worse.\n\nNow with that showing of my biases out of the way...\n\n> I think adding 'rm' to completion definitely counts as advertisement.\n> It doesn't have much practical use, after all: typing 'rm' with\n> completion is actually one more keystroke than without (rm vs. rm).\n\nThis is only one use of the completion interface, maybe you only use it\nlike that, but not everyone does.\n\nThe completion interface has two uses, one is to actually save you\ntyping, the other is subcommand discovery, and maybe someone who has a\nuse neither you or I have thought of is about to point out a third.\n\nI'll type \"git $whatever $subcommand\" as *validation* that I've\nfound the right command, not to complete it for me. This is a thing\nthat's in my muscle memory for everything.\n\nThe post-hoc reason is because if you're a fast typist you don't\nactually save time on typing the command (usually I just use reverse\nshell search anyway), but rather on not screwing up the command itself\nvia a typo.\n\nSometimes commands take a while to fail, and even if it's immediate\nre-editing them takes longer than getting it right in the first place.\n\nSince I've been typing \"git remote rm\" for a while (started before\nthis deprecation happened) I've actually been meaning to submit\ncompletion for \"rm\" since it works, not knowing about Duy's patch until\nnow.\n\nNow, even if someone disagrees that we should have \"rm\" at all I think\nthat in general we should not conflate two different things, one is\nwhether:\n\n git remote \n\nshows both \"rm\" and \"remove\" in the list, and the other is whether:\n\n git remote rm\n\nShould yield:\n\n git remote rm\n\nOr, as now happens:\n\n git remote rm\n\nI can see why we'd, in general, we'd like to not advertise certain\noptions for completion (due to deprecation, or just to avoid verbosity),\nbut complete them once they're unambiguously typed out.\n\nI don't know whether the bash completion interface supports making that\ndistinction, but it would be useful.\n"},{"id":"335554","messageId":"20171230005222.GT3693@zaya.teonanacatl.net","threadId":"47506","inReplyTo":"87y3ll6s0e.fsf@evledraar.gmail.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2017-12-30T00:52:22Z","receivedAt":"2017-12-30T00:52:33Z","isPatch":true,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n>> I think adding 'rm' to completion definitely counts as advertisement.\n>> It doesn't have much practical use, after all: typing 'rm' with\n>> completion is actually one more keystroke than without (rm vs. rm).\n> \n> This is only one use of the completion interface, maybe you only use it\n> like that, but not everyone does.\n> \n> The completion interface has two uses, one is to actually save you\n> typing, the other is subcommand discovery, and maybe someone who has a\n> use neither you or I have thought of is about to point out a third.\n> \n> I'll type \"git $whatever $subcommand\" as *validation* that I've\n> found the right command, not to complete it for me. This is a thing\n> that's in my muscle memory for everything.\n\nIs that meant to be in favor of including rm in the\ncompletion results or against? :)\n\n> Since I've been typing \"git remote rm\" for a while (started before\n> this deprecation happened) I've actually been meaning to submit\n> completion for \"rm\" since it works, not knowing about Duy's patch until\n> now.\n> \n> Now, even if someone disagrees that we should have \"rm\" at all I think\n> that in general we should not conflate two different things, one is\n> whether:\n> \n> git remote \n> \n> shows both \"rm\" and \"remove\" in the list, and the other is whether:\n> \n> git remote rm\n> \n> Should yield:\n> \n> git remote rm\n> \n> Or, as now happens:\n> \n> git remote rm\n> \n> I can see why we'd, in general, we'd like to not advertise certain\n> options for completion (due to deprecation, or just to avoid verbosity),\n> but complete them once they're unambiguously typed out.\n> \n> I don't know whether the bash completion interface supports making that\n> distinction, but it would be useful.\n\nIt can be done, though I think that it's probably better to\nsubtly lead people to use 'git remote remove' going forward,\nto keep things consistent. I don't have a strong preference\nfor or against the rm -> remove change, but since that's\nbeen done I think there's a benefit to keeping things\nconsistent in the UI. And I think that should also apply to\nnot offering completion for commands/subcommands/options\nwhich are only kept for backward compatibility.\n\nHere's one way to make 'git remote rm ' work without\nincluding it in the output of 'git remote ':\n\ndiff --git i/contrib/completion/git-completion.bash w/contrib/completion/git-completion.bash\nindex 3683c772c5..aa63f028ab 100644\n--- i/contrib/completion/git-completion.bash\n+++ w/contrib/completion/git-completion.bash\n@@ -2668,7 +2668,9 @@ _git_remote ()\n \t\tadd rename remove set-head set-branches\n \t\tget-url set-url show prune update\n \t\t\"\n-\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n+\t# Don't advertise rm by including it in subcommands, but complete\n+\t# remotes if it is used.\n+\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands rm\")\"\n \tif [ -z \"$subcommand\" ]; then\n \t\tcase \"$cur\" in\n \t\t--*)\n\nKeeping 'git remote rm' working to avoid breaking scripts is\none thing, but having it in the completion code makes it\nmore likely that it will continue to be seen as a\nrecommended subcommand.\n\nThis leads to patches like this one, where it's presumed\nthat the lack of completion is simply an oversight or a bug.\nOf course, the lack of completion hasn't caused everyone to\nforget that 'remote rm' was changed to 'remote remove', so\nthat reasoning may be full of hot air (or worse). ;)\n\nThe current result of 'git remote rm ' isn't so great.\nIt's arguably worse to have it pretend that no subcommand\nwas given than to list the remotes.\n\n$ git remote rm \nadd remove set-head update\nget-url rename set-url\nprune set-branches show\n\nI think completing nothing or completing the remotes\n(without offering rm in the subcommand list) would be\nbetter, after looking at it a bit.\n\nI don't know how to disable file completion, but I'm not\nintimately familiar with the git completion script (thanks\nto it working so damn well). I'm guessing there's a way to\ndo that, if there's a strong desire to not complete the\nremotes at all.\n\nI don't think we should include rm in 'git remote '\ncompletion, but I don't care much either way what 'git\nremote rm ' includes. But it should be better than\nincluding the other subcommands.\n\n-- \nTodd\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nThere, I've gone and soiled myself, are you happy now?!\n -- Stewie Griffin\n\n"},{"id":"335557","messageId":"87vago76i8.fsf@evledraar.gmail.com","threadId":"47506","inReplyTo":"20171230005222.GT3693@zaya.teonanacatl.net","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-12-30T12:19:27Z","receivedAt":"2017-12-30T12:19:36Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Dec 30 2017, Todd Zullinger jotted:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>>> I think adding 'rm' to completion definitely counts as advertisement.\n>>> It doesn't have much practical use, after all: typing 'rm' with\n>>> completion is actually one more keystroke than without (rm vs. rm).\n>>\n>> This is only one use of the completion interface, maybe you only use it\n>> like that, but not everyone does.\n>>\n>> The completion interface has two uses, one is to actually save you\n>> typing, the other is subcommand discovery, and maybe someone who has a\n>> use neither you or I have thought of is about to point out a third.\n>>\n>> I'll type \"git $whatever $subcommand\" as *validation* that I've\n>> found the right command, not to complete it for me. This is a thing\n>> that's in my muscle memory for everything.\n>\n> Is that meant to be in favor of including rm in the\n> completion results or against? :)\n\nFor.\n\n>> Since I've been typing \"git remote rm\" for a while (started before\n>> this deprecation happened) I've actually been meaning to submit\n>> completion for \"rm\" since it works, not knowing about Duy's patch until\n>> now.\n>>\n>> Now, even if someone disagrees that we should have \"rm\" at all I think\n>> that in general we should not conflate two different things, one is\n>> whether:\n>>\n>> git remote \n>>\n>> shows both \"rm\" and \"remove\" in the list, and the other is whether:\n>>\n>> git remote rm\n>>\n>> Should yield:\n>>\n>> git remote rm\n>>\n>> Or, as now happens:\n>>\n>> git remote rm\n>>\n>> I can see why we'd, in general, we'd like to not advertise certain\n>> options for completion (due to deprecation, or just to avoid verbosity),\n>> but complete them once they're unambiguously typed out.\n>>\n>> I don't know whether the bash completion interface supports making that\n>> distinction, but it would be useful.\n>\n> It can be done, though I think that it's probably better to\n> subtly lead people to use 'git remote remove' going forward,\n> to keep things consistent. I don't have a strong preference\n> for or against the rm -> remove change, but since that's\n> been done I think there's a benefit to keeping things\n> consistent in the UI.\n\nWe changed it in the past, we can always change it again, it's never too\nlate to fix the UI.\n\nNow whether we *should* change/fix this particular thing is another\nmatter. I'm just pointing out that we shouldn't fall into the trap of\nthinking that git's UI is an established platform that can't be changed.\n\nThe vast majority of people who'll ever use git will most likely start\nusing a version that we're going to release many years into the future.\n\nI'm reminded of the story about the guy who decided makefiles must have\ntabs, who didn't want to change it because he already had some dozens of\nusers.\n\n> And I think that should also apply to\n> not offering completion for commands/subcommands/options\n> which are only kept for backward compatibility.\n\nYeah I think it makes sense to at some point stop completing things if\nwe're going to remove stuff, if we decide to remove it.\n\n> Here's one way to make 'git remote rm ' work without\n> including it in the output of 'git remote ':\n>\n> diff --git i/contrib/completion/git-completion.bash w/contrib/completion/git-completion.bash\n> index 3683c772c5..aa63f028ab 100644\n> --- i/contrib/completion/git-completion.bash\n> +++ w/contrib/completion/git-completion.bash\n> @@ -2668,7 +2668,9 @@ _git_remote ()\n> \t\tadd rename remove set-head set-branches\n> \t\tget-url set-url show prune update\n> \t\t\"\n> -\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n> +\t# Don't advertise rm by including it in subcommands, but complete\n> +\t# remotes if it is used.\n> +\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands rm\")\"\n> \tif [ -z \"$subcommand\" ]; then\n> \t\tcase \"$cur\" in\n> \t\t--*)\n\nNeat!\n\n> Keeping 'git remote rm' working to avoid breaking scripts is\n> one thing, but having it in the completion code makes it\n> more likely that it will continue to be seen as a\n> recommended subcommand.\n>\n> This leads to patches like this one, where it's presumed\n> that the lack of completion is simply an oversight or a bug.\n> Of course, the lack of completion hasn't caused everyone to\n> forget that 'remote rm' was changed to 'remote remove', so\n> that reasoning may be full of hot air (or worse). ;)\n>\n> The current result of 'git remote rm ' isn't so great.\n> It's arguably worse to have it pretend that no subcommand\n> was given than to list the remotes.\n>\n> $ git remote rm \n> add remove set-head update\n> get-url rename set-url\n> prune set-branches show\n\nAlthough that's a bug that has nothing to do with remove/rm, because you\nalso get:\n\n $ git remote blahblah \n $ git rebase doesntexist \n\netc. showing you valid subcommands, when perhaps we should show\n\"warning: no such subcommand `blahblah`/`doesntexist`!\" instead.\n\n> I think completing nothing or completing the remotes\n> (without offering rm in the subcommand list) would be\n> better, after looking at it a bit.\n>\n> I don't know how to disable file completion, but I'm not\n> intimately familiar with the git completion script (thanks\n> to it working so damn well). I'm guessing there's a way to\n> do that, if there's a strong desire to not complete the\n> remotes at all.\n>\n> I don't think we should include rm in 'git remote '\n> completion, but I don't care much either way what 'git\n> remote rm ' includes. But it should be better than\n> including the other subcommands.\n"},{"id":"335589","messageId":"20171231204426.GA30674@bryant.local","threadId":"47506","inReplyTo":"87vago76i8.fsf@evledraar.gmail.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Keith Smiley","fromEmail":"k@keith.so","sentAt":"2017-12-31T20:44:26Z","receivedAt":"2017-12-31T20:44:34Z","isPatch":true,"sender":{"key":"k@keith.so","avatar":null},"body":"I'm definitely happy to update this patch for now to just complete the \nremote names, and not add rm to the list of subcommand completions if \nwe're all ok with that!\n\n--\nKeith Smiley\n\nOn 12/30, Ævar Arnfjörð Bjarmason wrote:\n>\n>On Sat, Dec 30 2017, Todd Zullinger jotted:\n>\n>> Ævar Arnfjörð Bjarmason wrote:\n>>>> I think adding 'rm' to completion definitely counts as advertisement.\n>>>> It doesn't have much practical use, after all: typing 'rm' with\n>>>> completion is actually one more keystroke than without (rm vs. rm).\n>>>\n>>> This is only one use of the completion interface, maybe you only use it\n>>> like that, but not everyone does.\n>>>\n>>> The completion interface has two uses, one is to actually save you\n>>> typing, the other is subcommand discovery, and maybe someone who has a\n>>> use neither you or I have thought of is about to point out a third.\n>>>\n>>> I'll type \"git $whatever $subcommand\" as *validation* that I've\n>>> found the right command, not to complete it for me. This is a thing\n>>> that's in my muscle memory for everything.\n>>\n>> Is that meant to be in favor of including rm in the\n>> completion results or against? :)\n>\n>For.\n>\n>>> Since I've been typing \"git remote rm\" for a while (started before\n>>> this deprecation happened) I've actually been meaning to submit\n>>> completion for \"rm\" since it works, not knowing about Duy's patch until\n>>> now.\n>>>\n>>> Now, even if someone disagrees that we should have \"rm\" at all I think\n>>> that in general we should not conflate two different things, one is\n>>> whether:\n>>>\n>>> git remote \n>>>\n>>> shows both \"rm\" and \"remove\" in the list, and the other is whether:\n>>>\n>>> git remote rm\n>>>\n>>> Should yield:\n>>>\n>>> git remote rm\n>>>\n>>> Or, as now happens:\n>>>\n>>> git remote rm\n>>>\n>>> I can see why we'd, in general, we'd like to not advertise certain\n>>> options for completion (due to deprecation, or just to avoid verbosity),\n>>> but complete them once they're unambiguously typed out.\n>>>\n>>> I don't know whether the bash completion interface supports making that\n>>> distinction, but it would be useful.\n>>\n>> It can be done, though I think that it's probably better to\n>> subtly lead people to use 'git remote remove' going forward,\n>> to keep things consistent. I don't have a strong preference\n>> for or against the rm -> remove change, but since that's\n>> been done I think there's a benefit to keeping things\n>> consistent in the UI.\n>\n>We changed it in the past, we can always change it again, it's never too\n>late to fix the UI.\n>\n>Now whether we *should* change/fix this particular thing is another\n>matter. I'm just pointing out that we shouldn't fall into the trap of\n>thinking that git's UI is an established platform that can't be changed.\n>\n>The vast majority of people who'll ever use git will most likely start\n>using a version that we're going to release many years into the future.\n>\n>I'm reminded of the story about the guy who decided makefiles must have\n>tabs, who didn't want to change it because he already had some dozens of\n>users.\n>\n>> And I think that should also apply to\n>> not offering completion for commands/subcommands/options\n>> which are only kept for backward compatibility.\n>\n>Yeah I think it makes sense to at some point stop completing things if\n>we're going to remove stuff, if we decide to remove it.\n>\n>> Here's one way to make 'git remote rm ' work without\n>> including it in the output of 'git remote ':\n>>\n>> diff --git i/contrib/completion/git-completion.bash w/contrib/completion/git-completion.bash\n>> index 3683c772c5..aa63f028ab 100644\n>> --- i/contrib/completion/git-completion.bash\n>> +++ w/contrib/completion/git-completion.bash\n>> @@ -2668,7 +2668,9 @@ _git_remote ()\n>> \t\tadd rename remove set-head set-branches\n>> \t\tget-url set-url show prune update\n>> \t\t\"\n>> -\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n>> +\t# Don't advertise rm by including it in subcommands, but complete\n>> +\t# remotes if it is used.\n>> +\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands rm\")\"\n>> \tif [ -z \"$subcommand\" ]; then\n>> \t\tcase \"$cur\" in\n>> \t\t--*)\n>\n>Neat!\n>\n>> Keeping 'git remote rm' working to avoid breaking scripts is\n>> one thing, but having it in the completion code makes it\n>> more likely that it will continue to be seen as a\n>> recommended subcommand.\n>>\n>> This leads to patches like this one, where it's presumed\n>> that the lack of completion is simply an oversight or a bug.\n>> Of course, the lack of completion hasn't caused everyone to\n>> forget that 'remote rm' was changed to 'remote remove', so\n>> that reasoning may be full of hot air (or worse). ;)\n>>\n>> The current result of 'git remote rm ' isn't so great.\n>> It's arguably worse to have it pretend that no subcommand\n>> was given than to list the remotes.\n>>\n>> $ git remote rm \n>> add remove set-head update\n>> get-url rename set-url\n>> prune set-branches show\n>\n>Although that's a bug that has nothing to do with remove/rm, because you\n>also get:\n>\n> $ git remote blahblah \n> $ git rebase doesntexist \n>\n>etc. showing you valid subcommands, when perhaps we should show\n>\"warning: no such subcommand `blahblah`/`doesntexist`!\" instead.\n>\n>> I think completing nothing or completing the remotes\n>> (without offering rm in the subcommand list) would be\n>> better, after looking at it a bit.\n>>\n>> I don't know how to disable file completion, but I'm not\n>> intimately familiar with the git completion script (thanks\n>> to it working so damn well). I'm guessing there's a way to\n>> do that, if there's a strong desire to not complete the\n>> remotes at all.\n>>\n>> I don't think we should include rm in 'git remote '\n>> completion, but I don't care much either way what 'git\n>> remote rm ' includes. But it should be better than\n>> including the other subcommands.\n"},{"id":"335602","messageId":"CACsJy8Bw5RLTRNjvRpuBO4_jbK2dTasapDjHsb-=Y_3op0+L8A@mail.gmail.com","threadId":"47506","inReplyTo":"20171229041927.GA83931@bryant.local","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-01-01T23:46:35Z","receivedAt":"2018-01-01T23:47:11Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Dec 29, 2017 at 11:19 AM, Keith Smiley wrote:\n> It looks like that was just about preferring remove in documentation and the\n> like, I think it would still make sense to have both for completion since rm\n> is still supported.\n\n'rm' should be deprecated. But because I did not really push for a\ndeprecation plan and 'rm' still remains after 5 years, I guess it may\nbe counted as \"supported\" too (or we can start the deprecation process\nnow).\n\n>> Keith Smiley wrote:\n>>>\n>>> Previously git remote rm did not complete your list of removes as remove\n>>> does.\n>>\n>>\n>> Looking through the history, the rm subcomand completion was\n>> explicitly removed in e17dba8fe1 (\"remote: prefer subcommand\n>> name 'remove' to 'rm'\", 2012-09-06).\n-- \nDuy\n"},{"id":"335770","messageId":"xmqq373miw4r.fsf@gitster.mtv.corp.google.com","threadId":"47506","inReplyTo":"87vago76i8.fsf@evledraar.gmail.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-01-03T19:24:04Z","receivedAt":"2018-01-03T19:24:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Sat, Dec 30 2017, Todd Zullinger jotted:\n>\n>> And I think that should also apply to\n>> not offering completion for commands/subcommands/options\n>> which are only kept for backward compatibility.\n>\n> Yeah I think it makes sense to at some point stop completing things if\n> we're going to remove stuff, if we decide to remove it.\n>\n>> Here's one way to make 'git remote rm ' work without\n>> including it in the output of 'git remote ':\n>>\n>> diff --git i/contrib/completion/git-completion.bash w/contrib/completion/git-completion.bash\n>> index 3683c772c5..aa63f028ab 100644\n>> --- i/contrib/completion/git-completion.bash\n>> +++ w/contrib/completion/git-completion.bash\n>> @@ -2668,7 +2668,9 @@ _git_remote ()\n>> \t\tadd rename remove set-head set-branches\n>> \t\tget-url set-url show prune update\n>> \t\t\"\n>> -\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n>> +\t# Don't advertise rm by including it in subcommands, but complete\n>> +\t# remotes if it is used.\n>> +\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands rm\")\"\n>> \tif [ -z \"$subcommand\" ]; then\n>> \t\tcase \"$cur\" in\n>> \t\t--*)\n>\n> Neat!\n\nYes, indeed it is nice.\n\n\n"},{"id":"336633","messageId":"1516052626.2870893.1236353440.65CA651A@webmail.messagingengine.com","threadId":"47506","inReplyTo":"xmqq373miw4r.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Keith Smiley","fromEmail":"k@keith.so","sentAt":"2018-01-15T21:43:46Z","receivedAt":"2018-01-15T21:43:52Z","isPatch":true,"sender":{"key":"k@keith.so","avatar":null},"body":"So it sounds like either we should deprecate rm, or I should update the patch to the suggested method where we just complete remotes, but not rm in the list of completions.\n\nThoughts?\n\n-- \nKeith Smiley\n\nOn Wed, Jan 3, 2018, at 11:24, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason writes:\n> \n> > On Sat, Dec 30 2017, Todd Zullinger jotted:\n> >\n> >> And I think that should also apply to\n> >> not offering completion for commands/subcommands/options\n> >> which are only kept for backward compatibility.\n> >\n> > Yeah I think it makes sense to at some point stop completing things if\n> > we're going to remove stuff, if we decide to remove it.\n> >\n> >> Here's one way to make 'git remote rm ' work without\n> >> including it in the output of 'git remote ':\n> >>\n> >> diff --git i/contrib/completion/git-completion.bash w/contrib/completion/git-completion.bash\n> >> index 3683c772c5..aa63f028ab 100644\n> >> --- i/contrib/completion/git-completion.bash\n> >> +++ w/contrib/completion/git-completion.bash\n> >> @@ -2668,7 +2668,9 @@ _git_remote ()\n> >> \t\tadd rename remove set-head set-branches\n> >> \t\tget-url set-url show prune update\n> >> \t\t\"\n> >> -\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n> >> +\t# Don't advertise rm by including it in subcommands, but complete\n> >> +\t# remotes if it is used.\n> >> +\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands rm\")\"\n> >> \tif [ -z \"$subcommand\" ]; then\n> >> \t\tcase \"$cur\" in\n> >> \t\t--*)\n> >\n> > Neat!\n> \n> Yes, indeed it is nice.\n> \n> \n"},{"id":"336651","messageId":"CACsJy8Dzv3qPc1dB1rdvYL+CvEp+hY8ddoBrbCiP5KnqikzyLw@mail.gmail.com","threadId":"47506","inReplyTo":"1516052626.2870893.1236353440.65CA651A@webmail.messagingengine.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-01-16T10:02:25Z","receivedAt":"2018-01-16T10:03:01Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote:\n> So it sounds like either we should deprecate rm, or I should update the patch to the suggested method where we just complete remotes, but not rm in the list of completions.\n\nI vote for deprecation. I could send a patch to start warning to\nswitch from 'rm' to 'remove'. Then perhaps we can delete it after two\nreleases. It's not classified as plumbing should we don't have worry\ntoo much about scripts relying on 'remote rm'.\n\n>\n> Thoughts?\n>\n> --\n> Keith Smiley\n-- \nDuy\n"},{"id":"336667","messageId":"xmqqh8rlvdgh.fsf@gitster.mtv.corp.google.com","threadId":"47506","inReplyTo":"CACsJy8Dzv3qPc1dB1rdvYL+CvEp+hY8ddoBrbCiP5KnqikzyLw@mail.gmail.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-01-16T18:57:34Z","receivedAt":"2018-01-16T18:57:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote:\n>> So it sounds like either we should deprecate rm, or I should update the patch to the suggested method where we just complete remotes, but not rm in the list of completions.\n>\n> I vote for deprecation. I could send a patch to start warning to\n> switch from 'rm' to 'remove'. Then perhaps we can delete it after two\n> releases. It's not classified as plumbing should we don't have worry\n> too much about scripts relying on 'remote rm'.\n\nI do not know about \"two releases\" part (which amounts to merely\n20-24 weeks), but looking at \"git remote -h\" output and seeing that\nwe do spell out \"rename\" (instead of saying \"mv\" or something cryptic),\nit probably makes sense to remove \"rm\" some time in the future.\n\nI actually do think \"rm\" is _already_ deprecated. \n\n\"git remote --help\" does not mention it in its synopsis section and\nit merely has \", rm\" after \"remove\" as if an afterthought. I am not\nsure if it is worth being more explicit, perhaps like this?\n\n Documentation/git-remote.txt | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt\nindex 577b969c1b..149db90346 100644\n--- a/Documentation/git-remote.txt\n+++ b/Documentation/git-remote.txt\n@@ -93,7 +93,8 @@ the configuration file format.\n 'rm'::\n \n Remove the remote named . All remote-tracking branches and\n-configuration settings for the remote are removed.\n+configuration settings for the remote are removed. `rm` is a deprecated\n+synonym that will be removed in future versions of Git.\n \n 'set-head'::\n \n"},{"id":"336685","messageId":"20180117004419.GA14263@duynguyen.dek-tpc.internal","threadId":"47506","inReplyTo":"xmqqh8rlvdgh.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-01-17T00:44:19Z","receivedAt":"2018-01-17T00:44:36Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Jan 16, 2018 at 10:57:34AM -0800, Junio C Hamano wrote:\n> Duy Nguyen writes:\n> \n> > On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote:\n> >> So it sounds like either we should deprecate rm, or I should update the patch to the suggested method where we just complete remotes, but not rm in the list of completions.\n> >\n> > I vote for deprecation. I could send a patch to start warning to\n> > switch from 'rm' to 'remove'. Then perhaps we can delete it after two\n> > releases. It's not classified as plumbing should we don't have worry\n> > too much about scripts relying on 'remote rm'.\n> \n> I do not know about \"two releases\" part (which amounts to merely\n> 20-24 weeks), but looking at \"git remote -h\" output and seeing that\n> we do spell out \"rename\" (instead of saying \"mv\" or something cryptic),\n> it probably makes sense to remove \"rm\" some time in the future.\n> \n> I actually do think \"rm\" is _already_ deprecated. \n> \n> \"git remote --help\" does not mention it in its synopsis section and\n> it merely has \", rm\" after \"remove\" as if an afterthought.\n\nIt's actually my bad. I should have replaced 'rm' with 'remove' in\ngit-remote.txt in e17dba8fe1 (remote: prefer subcommand name 'remove'\nto 'rm' - 2012-09-06)\n\n> I am not sure if it is worth being more explicit, perhaps like this?\n\nLooks good. If we want to be more careful, we can follow up with\nsomething even more annoying like this before removing 'rm'\n\n-- 8< --\ndiff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt\nindex 577b969c1b..0a544703e6 100644\n--- a/Documentation/git-remote.txt\n+++ b/Documentation/git-remote.txt\n@@ -90,7 +90,6 @@ In case and are the same, and is a file under\n the configuration file format.\n \n 'remove'::\n-'rm'::\n \n Remove the remote named . All remote-tracking branches and\n configuration settings for the remote are removed.\ndiff --git a/builtin/remote.c b/builtin/remote.c\nindex d95bf904c3..774ef6931e 100644\n--- a/builtin/remote.c\n+++ b/builtin/remote.c\n@@ -1609,7 +1609,10 @@ int cmd_remote(int argc, const char **argv, const char *prefix)\n \t\tresult = add(argc, argv);\n \telse if (!strcmp(argv[0], \"rename\"))\n \t\tresult = mv(argc, argv);\n-\telse if (!strcmp(argv[0], \"rm\") || !strcmp(argv[0], \"remove\"))\n+\telse if (!strcmp(argv[0], \"rm\")) {\n+\t\twarning(_(\"'rm' is a deprecated synonym. Use 'remove' instead.\"));\n+\t\tresult = rm(argc, argv);\n+\t} else if (!strcmp(argv[0], \"remove\"))\n \t\tresult = rm(argc, argv);\n \telse if (!strcmp(argv[0], \"set-head\"))\n \t\tresult = set_head(argc, argv);\n-- 8< --\n\nPS. This also makes me thing about supporting subcommand aliases, so\nthat people can add back 'git remote rm' if they like (or something\nlike 'git r rm' when they alias 'remote' as well). Which is probably a\ngood thing to do. Long command names are fine when you have completion\nsupport, they are a pain to type otherwise.\n\n--\nDuy\n"},{"id":"336691","messageId":"20180117061703.GB5618@alpha.vpn.ikke.info","threadId":"47506","inReplyTo":"20180117004419.GA14263@duynguyen.dek-tpc.internal","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2018-01-17T06:17:04Z","receivedAt":"2018-01-17T06:17:11Z","isPatch":true,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Wed, Jan 17, 2018 at 07:44:19AM +0700, Duy Nguyen wrote:\n> On Tue, Jan 16, 2018 at 10:57:34AM -0800, Junio C Hamano wrote:\n> > Duy Nguyen writes:\n> > \n> > > On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote:\n> > >> So it sounds like either we should deprecate rm, or I should update the patch to the suggested method where we just complete remotes, but not rm in the list of completions.\n> > >\n> > > I vote for deprecation. I could send a patch to start warning to\n> > > switch from 'rm' to 'remove'. Then perhaps we can delete it after two\n> > > releases. It's not classified as plumbing should we don't have worry\n> > > too much about scripts relying on 'remote rm'.\n> > \n> > I do not know about \"two releases\" part (which amounts to merely\n> > 20-24 weeks), but looking at \"git remote -h\" output and seeing that\n> > we do spell out \"rename\" (instead of saying \"mv\" or something cryptic),\n> > it probably makes sense to remove \"rm\" some time in the future.\n> > \n> > I actually do think \"rm\" is _already_ deprecated. \n> > \n> > \"git remote --help\" does not mention it in its synopsis section and\n> > it merely has \", rm\" after \"remove\" as if an afterthought.\n> \n> It's actually my bad. I should have replaced 'rm' with 'remove' in\n> git-remote.txt in e17dba8fe1 (remote: prefer subcommand name 'remove'\n> to 'rm' - 2012-09-06)\n> \n> > I am not sure if it is worth being more explicit, perhaps like this?\n> \n> Looks good. If we want to be more careful, we can follow up with\n> something even more annoying like this before removing 'rm'\n> \n> -- 8< --\n> diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt\n> index 577b969c1b..0a544703e6 100644\n> --- a/Documentation/git-remote.txt\n> +++ b/Documentation/git-remote.txt\n> @@ -90,7 +90,6 @@ In case and are the same, and is a file under\n> the configuration file format.\n> \n> 'remove'::\n> -'rm'::\n> \n> Remove the remote named . All remote-tracking branches and\n> configuration settings for the remote are removed.\n> diff --git a/builtin/remote.c b/builtin/remote.c\n> index d95bf904c3..774ef6931e 100644\n> --- a/builtin/remote.c\n> +++ b/builtin/remote.c\n> @@ -1609,7 +1609,10 @@ int cmd_remote(int argc, const char **argv, const char *prefix)\n> \t\tresult = add(argc, argv);\n> \telse if (!strcmp(argv[0], \"rename\"))\n> \t\tresult = mv(argc, argv);\n> -\telse if (!strcmp(argv[0], \"rm\") || !strcmp(argv[0], \"remove\"))\n> +\telse if (!strcmp(argv[0], \"rm\")) {\n> +\t\twarning(_(\"'rm' is a deprecated synonym. Use 'remove' instead.\"));\n> +\t\tresult = rm(argc, argv);\n> +\t} else if (!strcmp(argv[0], \"remove\"))\n> \t\tresult = rm(argc, argv);\n> \telse if (!strcmp(argv[0], \"set-head\"))\n> \t\tresult = set_head(argc, argv);\n> -- 8< --\n> \n> PS. This also makes me thing about supporting subcommand aliases, so\n> that people can add back 'git remote rm' if they like (or something\n> like 'git r rm' when they alias 'remote' as well). Which is probably a\n> good thing to do. Long command names are fine when you have completion\n> support, they are a pain to type otherwise.\n> \n\nCouldn't they just create an alias like git rrm then, if they use it so\noften that it becomes an issue? Having another layer of aliases does\ncreate a lot of complexity.\n\n> --\n> Duy\n"},{"id":"336694","messageId":"CACsJy8C0f43cc5TuybEo5wmem9MSdTO+-0tF3c9k4siN1UgwwQ@mail.gmail.com","threadId":"47506","inReplyTo":"20180117061703.GB5618@alpha.vpn.ikke.info","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-01-17T09:48:02Z","receivedAt":"2018-01-17T09:48:40Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Jan 17, 2018 at 1:17 PM, Kevin Daudt wrote:\n> On Wed, Jan 17, 2018 at 07:44:19AM +0700, Duy Nguyen wrote:\n>> PS. This also makes me thing about supporting subcommand aliases, so\n>> that people can add back 'git remote rm' if they like (or something\n>> like 'git r rm' when they alias 'remote' as well). Which is probably a\n>> good thing to do. Long command names are fine when you have completion\n>> support, they are a pain to type otherwise.\n>>\n>\n> Couldn't they just create an alias like git rrm then, if they use it so\n> often that it becomes an issue?\n\nThey could. The only exception that may not work is if they want to\ninsert some options between \"r\" and \"rm\". Sometimes option positions\nmatter. Anyway this is just thinking out loud, maybe we don't really\nneed it until people scream about it with a valid use case\n\n> Having another layer of aliases does create a lot of complexity.\n\nYes. It's partly the reason I wanted this actually ;-) Many commands\nhave gained subcommands nowadays but there's no shared infrastructure\nfor managing these subcommands. By adding something that works across\nthe board at subcommand level I'm forced to \"fix\" this (or probably\nnever get to do the sub-aliasing because this \"fix\" takes forever).\n-- \nDuy\n"},{"id":"336707","messageId":"xmqqshb4s5y7.fsf@gitster.mtv.corp.google.com","threadId":"47506","inReplyTo":"20180117004419.GA14263@duynguyen.dek-tpc.internal","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-01-17T18:20:16Z","receivedAt":"2018-01-17T18:20:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> Looks good. If we want to be more careful, we can follow up with\n> something even more annoying like this before removing 'rm'\n>\n> -- 8< --\n> diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt\n> index 577b969c1b..0a544703e6 100644\n> --- a/Documentation/git-remote.txt\n> +++ b/Documentation/git-remote.txt\n> @@ -90,7 +90,6 @@ In case and are the same, and is a file under\n> the configuration file format.\n> \n> 'remove'::\n> -'rm'::\n> \n> Remove the remote named . All remote-tracking branches and\n> configuration settings for the remote are removed.\n> diff --git a/builtin/remote.c b/builtin/remote.c\n> index d95bf904c3..774ef6931e 100644\n> --- a/builtin/remote.c\n> +++ b/builtin/remote.c\n> @@ -1609,7 +1609,10 @@ int cmd_remote(int argc, const char **argv, const char *prefix)\n> \t\tresult = add(argc, argv);\n> \telse if (!strcmp(argv[0], \"rename\"))\n> \t\tresult = mv(argc, argv);\n> -\telse if (!strcmp(argv[0], \"rm\") || !strcmp(argv[0], \"remove\"))\n> +\telse if (!strcmp(argv[0], \"rm\")) {\n> +\t\twarning(_(\"'rm' is a deprecated synonym. Use 'remove' instead.\"));\n> +\t\tresult = rm(argc, argv);\n> +\t} else if (!strcmp(argv[0], \"remove\"))\n> \t\tresult = rm(argc, argv);\n> \telse if (!strcmp(argv[0], \"set-head\"))\n> \t\tresult = set_head(argc, argv);\n> -- 8< --\n\nYes, this is a sensible way to properly deprecate it further before\nremoval.\n"},{"id":"352625","messageId":"86CBC1AA-2AE2-4C58-A7BC-A6AD3A3B822D@keith.so","threadId":"47506","inReplyTo":"CACsJy8C0f43cc5TuybEo5wmem9MSdTO+-0tF3c9k4siN1UgwwQ@mail.gmail.com","subject":"Re: [PATCH] Add shell completion for git remote rm","fromName":"Keith Smiley","fromEmail":"k@keith.so","sentAt":"2018-07-16T13:12:58Z","receivedAt":"2018-07-16T13:21:08Z","isPatch":true,"sender":{"key":"k@keith.so","avatar":null},"body":"Since there hasn't been any movement on the alternative solutions mentioned here, would it be reasonable to accept this patch in the meantime?\n\n\n--\nKeith Smiley\n\n> On Jan 17, 2018, at 01:48, Duy Nguyen wrote:\n> \n>> On Wed, Jan 17, 2018 at 1:17 PM, Kevin Daudt wrote:\n>>> On Wed, Jan 17, 2018 at 07:44:19AM +0700, Duy Nguyen wrote:\n>>> PS. This also makes me thing about supporting subcommand aliases, so\n>>> that people can add back 'git remote rm' if they like (or something\n>>> like 'git r rm' when they alias 'remote' as well). Which is probably a\n>>> good thing to do. Long command names are fine when you have completion\n>>> support, they are a pain to type otherwise.\n>>> \n>> \n>> Couldn't they just create an alias like git rrm then, if they use it so\n>> often that it becomes an issue?\n> \n> They could. The only exception that may not work is if they want to\n> insert some options between \"r\" and \"rm\". Sometimes option positions\n> matter. Anyway this is just thinking out loud, maybe we don't really\n> need it until people scream about it with a valid use case\n> \n>> Having another layer of aliases does create a lot of complexity.\n> \n> Yes. It's partly the reason I wanted this actually ;-) Many commands\n> have gained subcommands nowadays but there's no shared infrastructure\n> for managing these subcommands. By adding something that works across\n> the board at subcommand level I'm forced to \"fix\" this (or probably\n> never get to do the sub-aliasing because this \"fix\" takes forever).\n> -- \n> Duy\n\n"}]}