Re: [PATCH] parse-options: don't complete option aliases by default

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Jul 15, 2021, 17:16 UTC
Message-ID: <60f06d62868db_4b6820816@natae.notmuch>
In-Reply-To: <8735sfzgkg.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason wrote:

> On Thu, Jul 15 2021, Philippe Blain via GitGitGadget wrote:

Show 5 quoted lines

> I'm a bit biased here since I like --recursive better, but let's not
> drag that whole argument up again. I don't find the argument in
> bb62e0a99fc (clone: teach --recurse-submodules to optionally take a
> pathspec, 2017-03-17) convincing enough to have moved such a prominent
> use-case to a longer option name.

I agree.

Show 6 quoted lines

> But, water under the bridge. Aside from that:
> 
> For me a Google search for "git clone --recursive" is ~40k results, but
> "git clone --recurse-submodules". The former links to various
> discussions/docs/stackoverflow answers, often --recurse-submodules isn't
> mentioned at all or as an aside.

It would be nice if facts could be used as evidence of a UI mistake, but alas in my experience that has never been the case.

Show 5 quoted lines

> I think it's unfortunate that we:
> 
>  1. Conflate whether something shows up in completion v.s. the
>     help. Given its prominence and that "git clone -h" is ~50 lines why
>     not note --recursive there.

Agreed.

>  2. Don't have the completion aware of these aliases, i.e. "git clone
>     --rec<TAB>" before your chance offers a completion of both, that sucks,
>     we should fully complete the non-alias instead.

Yes, that's what would happen with the patch.

Show 8 quoted lines

>  3. Making it PARSE_OPT_HIDDEN "solves" #2 at the cost of hiding it in
>     "git help -h", and now this won't work, but did before:
> 
>         git clone --recursi<TAB>
> 
>     I.e. even if we didn't want to do #2 *and* wanted to hide it in the
>     usage output surely completing an unmbigous prefix is better, even
>     if it's a hidden option?

This is something that could be done in zsh, but not in bash (at least not easily).

> E.g. the user has used --recursive for years, but can't even find it in
> -h (I also think it's a mistake to have entirely removed it from the
> docs, even if one agrees with its "deprecation" I'd say we should keep
> some "used to be called --recursive" note there).

But that is not a problem of this patch. If users can't find --recursive and complain about it, then that's actually a good thing, because now the facts about --recursive vs. --recurse-submodules are not needed anymore, and we could just fix the interface.

-- 
Felipe Contreras