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. Thoughts? -- Keith Smiley On Wed, Jan 3, 2018, at 11:24, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > > > On Sat, Dec 30 2017, Todd Zullinger jotted: > > > >> And I think that should also apply to > >> not offering completion for commands/subcommands/options > >> which are only kept for backward compatibility. > > > > Yeah I think it makes sense to at some point stop completing things if > > we're going to remove stuff, if we decide to remove it. > > > >> Here's one way to make 'git remote rm <TAB>' work without > >> including it in the output of 'git remote <TAB>': > >> > >> diff --git i/contrib/completion/git-completion.bash w/contrib/completion/git-completion.bash > >> index 3683c772c5..aa63f028ab 100644 > >> --- i/contrib/completion/git-completion.bash > >> +++ w/contrib/completion/git-completion.bash > >> @@ -2668,7 +2668,9 @@ _git_remote () > >> add rename remove set-head set-branches > >> get-url set-url show prune update > >> " > >> - local subcommand="$(__git_find_on_cmdline "$subcommands")" > >> + # Don't advertise rm by including it in subcommands, but complete > >> + # remotes if it is used. > >> + local subcommand="$(__git_find_on_cmdline "$subcommands rm")" > >> if [ -z "$subcommand" ]; then > >> case "$cur" in > >> --*) > > > > Neat! > > Yes, indeed it is nice. > >
