git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Thomas Gummerer <t.gummerer@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "SZEDER Gábor" <szeder.dev@gmail.com>
Subject: Re: [PATCH 0/3] completion: improvements for git stash
Date: Wed, 18 Apr 2018 22:15:52 +0100	[thread overview]
Message-ID: <20180418211552.GA31895@hank> (raw)
In-Reply-To: <xmqqh8o8j4ni.fsf@gitster-ct.c.googlers.com>

On 04/18, Junio C Hamano wrote:
> 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.

Fair enough.  I vaguely remembered this thread [1], that tried to add
'rm' back to the autocompletion after it was removed originally to try
and start the deprecation process.  Reading the thread again now
though it seems what you outline below to just not show "save" when
"git stash <TAB>" or "git stash s<TAB>" is typed makes more sense as a
step now.

I also notice that we never seemed to have taken any of the
suggestions made there (either adding 'rm' back to the completion
options, or going further in the deprecation process), though that's a
different topic :)

> 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 for the suggestions, I'll take a closer look at what could be
done, and will send a re-roll.

> Thanks.

[1]: 01020160a0004473-277c3d7c-4e3b-4c50-9d44-4a106f37f1d9-000000@eu-west-1.amazonses.com

  reply	other threads:[~2018-04-18 21:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-17 21:29 [PATCH 0/3] completion: improvements for git stash Thomas Gummerer
2018-04-17 21:29 ` [PATCH 1/3] completion: rename save_opts to default_opts for stash Thomas Gummerer
2018-04-17 21:29 ` [PATCH 2/3] completion: stop completing 'save' as stash subcommand Thomas Gummerer
2018-04-17 21:29 ` [PATCH 3/3] completion: make stash -p and alias for stash push -p Thomas Gummerer
2018-04-18  8:32 ` [PATCH 0/3] completion: improvements for git stash Junio C Hamano
2018-04-18 21:15   ` Thomas Gummerer [this message]
2018-04-19 23:25 ` [PATCH v2 0/2] " Thomas Gummerer
2018-04-19 23:25   ` [PATCH v2 1/2] completion: stop showing 'save' for stash by default Thomas Gummerer
2018-04-20  5:17     ` Duy Nguyen
2018-04-22 20:36       ` Thomas Gummerer
2018-04-19 23:25   ` [PATCH v2 2/2] completion: make stash -p and alias for stash push -p Thomas Gummerer
2018-04-20  1:38   ` [PATCH v2 0/2] completion: improvements for git stash Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180418211552.GA31895@hank \
    --to=t.gummerer@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=szeder.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).