git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Cornelius Weig <cornelius.weig@tngtech.com>
Cc: j6t@kdbg.org, Shawn Pearce <spearce@spearce.org>, git@vger.kernel.org
Subject: Re: [PATCH v2 7/7] completion: recognize more long-options
Date: Thu, 2 Feb 2017 03:00:08 +0100	[thread overview]
Message-ID: <CAM0VKjkAnsT_LE4OZRkLPuiEZW88P7_OBbOw0XovHhLYfBhbwg@mail.gmail.com> (raw)
In-Reply-To: <2841d2de-32ad-eae8-6039-9251a40bb00e@tngtech.com>

On Wed, Feb 1, 2017 at 5:49 PM, Cornelius Weig
<cornelius.weig@tngtech.com> wrote:
> Hi Gabor,
>
>  thanks for taking a look at these commits.
>
> On 01/31/2017 11:17 PM, SZEDER Gábor wrote:
>> On Fri, Jan 27, 2017 at 10:17 PM,  <cornelius.weig@tngtech.com> wrote:
>>> From: Cornelius Weig <cornelius.weig@tngtech.com>
>>>
>>> Recognize several new long-options for bash completion in the following
>>> commands:
>>
>> Adding more long options that git commands learn along the way is
>> always an improvement.  However, seeing "_several_ new long options"
>> (or "some long options" in one of the other patches in the series)
>> makes the reader wonder: are these the only new long options missing
>> or are there more?  If there are more, why only these are added?  If
>> there aren't any more missing long options left, then please say so,
>> e.g. "Add all missing long options, except the potentially
>> desctructive ones, for the following commands: ...."
>
> Personally, I agree with you that
>> Adding more long options that git commands learn along the way is
>> always an improvement.
> However, people may start complaining that their terminal becomes too
> cluttered when doing a double-Tab. In my cover letter, I go to length
> about this. My assumption was that all options that are mentioned in the
> introduction of the command man-page should be important enough to have
> them in the completion list.

But that doesn't mean that the ones not mentioned in the synopsis
section are not worth completing.

The list of options listed by the completion script for several of
these commands fits on a single line.  The command with the most
options among these is 'git pull', and even its options don't fill
more than half of a 80x25 screen.  I see no danger of people coming
complaining.

> I'll change my commit message accordingly.
>
>>>  - rm: --force
>>
>> '--force' is a potentially destructive option, too.
>
> Thanks for spotting this.
>
> Btw, I haven't found that non-destructive options should not be eligible
> for completion. To avoid confusion about this in the future, I suggest
> to also change the documentation:
>
> index 933bb6e..96f1c7f 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -13,7 +13,7 @@
>  #    *) git email aliases for git-send-email
>  #    *) tree paths within 'ref:path/to/file' expressions
>  #    *) file paths within current working directory and index
> -#    *) common --long-options
> +#    *) common non-destructive --long-options

I don't mind such a change, but I don't think that list was ever meant
to be comprehensive or decisive.  It is definitely not the former, as
it's missing several things that the completion script does support.
OTOH, it talks about .git/remotes, which has been considered legacy
for quite some years (though it's right, because the completion script
still supports it).

> I take it you have also looked at the code itself? Then I would gladly
> mention you as reviewer in my sign-off.

Yeah, most of the changes was rather straightforward, except the
completion of 'git remote's subcommands' options, but that looks
good, too.

Gábor

  reply	other threads:[~2017-02-02  2:00 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-22 22:57 [PATCH 0/7] completion bash: add more options and commands bitte.keine.werbung.einwerfen
2017-01-22 22:57 ` [PATCH 1/7] completion: teach options to submodule subcommands bitte.keine.werbung.einwerfen
2017-01-22 22:57 ` [PATCH 2/7] completion: add subcommand completion for rerere bitte.keine.werbung.einwerfen
2017-02-02  0:57   ` SZEDER Gábor
2017-02-02  9:16     ` Cornelius Weig
2017-01-22 22:57 ` [PATCH 3/7] completion: improve bash completion for git-add bitte.keine.werbung.einwerfen
2017-01-22 22:57 ` [PATCH 4/7] completion: teach ls-remote to complete options bitte.keine.werbung.einwerfen
2017-02-02  1:40   ` SZEDER Gábor
2017-02-02  9:40     ` Cornelius Weig
2017-02-02 16:57       ` Junio C Hamano
2017-01-22 22:57 ` [PATCH 5/7] completion: teach replace " bitte.keine.werbung.einwerfen
2017-01-22 22:57 ` [PATCH 6/7] completion: teach remote subcommands option completion bitte.keine.werbung.einwerfen
2017-02-02  1:37   ` SZEDER Gábor
2017-02-02 10:29     ` Cornelius Weig
2017-01-22 22:57 ` [PATCH 7/7] completion: recognize more long-options bitte.keine.werbung.einwerfen
2017-01-24  7:15   ` Johannes Sixt
2017-01-24  8:14     ` Cornelius Weig
2017-01-24 23:24       ` Junio C Hamano
2017-01-24 23:33         ` Cornelius Weig
2017-01-24 23:43           ` Stefan Beller
2017-01-25  0:11             ` Cornelius Weig
2017-01-25  0:21               ` Stefan Beller
2017-01-25  0:43                 ` Cornelius Weig
2017-01-25  0:52                   ` Re: Stefan Beller
2017-01-25  0:54                 ` Re: Linus Torvalds
2017-01-25  1:32                   ` Re: Eric Wong
2017-01-25  6:54                 ` SubmittingPatches: drop temporal reference for PGP signing Philip Oakley
2017-01-25 22:38                   ` Stefan Beller
2017-01-26 13:30                     ` Cornelius Weig
2017-01-26 17:57                       ` Stefan Beller
2017-01-26 18:18                       ` Junio C Hamano
2017-01-26 20:58                         ` Philip Oakley
2017-01-27 10:49                           ` Cornelius Weig
2017-01-27 17:43                             ` Junio C Hamano
2017-01-27 21:17     ` [PATCH v2 0/7] completion: recognize more long-options cornelius.weig
2017-01-27 21:17       ` [PATCH v2 7/7] " cornelius.weig
2017-01-31 22:17         ` SZEDER Gábor
2017-02-01 16:49           ` Cornelius Weig
2017-02-02  2:00             ` SZEDER Gábor [this message]
2017-02-02 10:40               ` Cornelius Weig
2017-01-31 22:42 ` [PATCH 3/7] completion: improve bash completion for git-add SZEDER Gábor
2017-02-03 11:01 [PATCH v2 0/7] completion bash: add more options and commands cornelius.weig
2017-02-03 11:01 ` [PATCH v2 7/7] completion: recognize more long-options cornelius.weig

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

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

  git send-email \
    --in-reply-to=CAM0VKjkAnsT_LE4OZRkLPuiEZW88P7_OBbOw0XovHhLYfBhbwg@mail.gmail.com \
    --to=szeder.dev@gmail.com \
    --cc=cornelius.weig@tngtech.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=spearce@spearce.org \
    /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.
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 NNTP newsgroup(s).