Re: [PATCH v2 7/7] completion: recognize more long-options

On 02/02/2017 03:00 AM, SZEDER Gábor wrote:

quoted

Personally, I agree with you that

quoted

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.

Absolutely. What I meant is that at least the options from the synopsis
should be contained in the set of completable options.

quoted

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).

Then let's not do that change, because for some commands destructive
long-options have been in the list of completed options for quite a
while. Given that, the above change of the documentation, might stir up
more confusion than it settles.