Thomas Gummerer <t.gummerer@xxxxxxxxx> 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.
