Re: [PATCH 0/3] completion: improvements for git stash

[Junio C Hamano <gitster@pobox.com>]

Thomas Gummerer <t.gummerer@gmail.com> writes:

> In this series we stop completing the 'git stash save' subcommand in
> git-completion.bash.  The command has been deprecated for a while,...

Anything deprecated in Oct 2017 is still too young in Git's
timescale, but this is the right thing to do in the longer term.

Regarding [2/3], I think 

 - It is perfectly fine to stop offering "save" among the choices
   when "git stash <TAB>" is given, so that we AVOID actively
   suggesting "save" to those who do not know (or do not want to
   learn) about it.  Instead we would knudge them towards "push".
   After all, that is what "deprecation" is all about.

 - It also is OK to limit the offering to "show" against "git stash
   s<TAB>", even though the user _could_ have meant "save" than the
   above case with totally empty subcommand name.

 - It is questionable to stop offering "save" to "git stash
   sav<TAB>" it is clear that the user wants to say "save" in this
   case, as there is no other subcommand the user could have meant.

 - It is outright hostile to the end user if we stop completing "git
   stash save --q<TAB>" with "--quiet".  At that point, we _know_
   that the user wants "save", and getting in the way of those who
   know what they are using does not feel quite right.

Of course, being more accomodating to existing users by taking the
last two points above seriously would raise a separate issue of when
we stop doing so, and if we should start doing something else.  If
there is a way to implement a "reluctant completion" that gives
"save" as a completion choice while giving a deprecation warning to
let the user know of the plan for removal of "save", that would be
good, for example.

Thanks.