From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id B1C651F66E for ; Wed, 19 Aug 2020 20:51:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727093AbgHSUv1 (ORCPT ); Wed, 19 Aug 2020 16:51:27 -0400 Received: from mail-40133.protonmail.ch ([185.70.40.133]:34673 "EHLO mail-40133.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725275AbgHSUvZ (ORCPT ); Wed, 19 Aug 2020 16:51:25 -0400 Date: Wed, 19 Aug 2020 20:51:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtzoeller.com; s=protonmail; t=1597870281; bh=3v/dV7PVN3/OFTvsQkkLcdP7vmqA0oZV5YpG8bz5jNI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=LA7+19kHPMIDCMjh+WjM6ctuLNH23imTBcmxHLtrY0abdPDzhUcAyR97YPCZTopqL +VhOEmDU7ndJUBB50rCmT91aKxIbNaRdotMAfzu1bC9Zzxd9s2JAyMwwlF0JmBWEzC H/YDQahZJzwrw9anY9zjmqOBCqj4T2vfvyrk0CW4= To: Junio C Hamano From: Ryan Zoeller Cc: git@vger.kernel.org Reply-To: Ryan Zoeller Subject: Re: [RFC PATCH 1/2] parse-options: add --git-completion-helper-all Message-ID: In-Reply-To: References: <20200819175047.692962-1-rtzoeller@rtzoeller.com> <20200819175047.692962-2-rtzoeller@rtzoeller.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On 8/19/20 2:39 PM, Junio C Hamano wrote: >=20 > Ryan Zoeller writes: >=20 >> --git-completion-helper excludes hidden options, such as --allow-empty >> for git commit. This is typically helpful, but occasionally we want >> auto-completion for obscure flags. >=20 > Hits from "git grep -B2 OPT_NOCOMPLETE" tells me that these are > mostly unsafe options. Those who accept the risk by saying > "complete all" should be allowed to see them. >=20 > The same with OPT_HIDDEN (including OPT_HIDDEN_) gives us a > mixed bag. Many are unsafe, some are uncommon and the rest are > discouraged, or old synonym to some other option that does get > completed. I am not sure if letting them be completed is an overall > win or makes the output from "git cmd --" too noisy. If options marked OPT_HIDDEN are considered too internal to meaningfully expose, I'm happy to hide them. I defaulted to "show everything", and backing off from that is easy enough. >=20 >> --git-completion-helper-all returns >> all options, even if they are marked as hidden or nocomplete. >=20 > If it is "occasinally", why is the removal of OPT_HIDDEN in > show_negated_gitcomp() unconditional? It shouldn't have been. I visually clumped the calls to it as being inside the for loop, and assumed they were being skipped over as part of the continue. >=20 >> Signed-off-by: Ryan Zoeller >> --- >> parse-options.c | 18 ++++++++++++------ >> 1 file changed, 12 insertions(+), 6 deletions(-) >> >> diff --git a/parse-options.c b/parse-options.c >> index c57618d537..cc7239e1c6 100644 >> --- a/parse-options.c >> +++ b/parse-options.c >> @@ -535,8 +535,9 @@ static void show_negated_gitcomp(const struct option= *opts, int nr_noopts) >> >> =09=09if (!opts->long_name) >> =09=09=09continue; >> -=09=09if (opts->flags & (PARSE_OPT_HIDDEN | PARSE_OPT_NOCOMPLETE)) >> -=09=09=09continue; >> +=09=09/* Don't check PARSE_OPT_HIDDEN or PARSE_OPT_NOCOMPLETE, >> +=09=09 * we expect the caller to handle these appropriately. >> +=09=09 */ >=20 > =09/* > =09 * Style: our multi-line comments should begin with > =09 * slash-asterisk alone on its own line, and end with > =09 * asterisk-slash also on its own line, like this. > =09 */ >=20 > We do not run around and fix existing style violations that would > only raise the patch noise, but we try not to introduce new > violators. Will fix. >=20 > I am not sure what the new comment says is justifiable. The only > caller of show_negated_gitcomp() is in show_gitcomp() where the > function looped over the options and showed the options normally, > honoring these two flags, but then the original list of options > are passed to this function without filtering any option element > on the list that are marked with these bits, so "the caller" > apparently is not interested in handling the elements with these > bits when making the decision to show "--no-