Re: [PATCH 1/2] completion: take into account the formatting backticks for options

From: Jean-Noël AVILA <jn.avila@free.fr>
Date: Mar 18, 2025, 04:27 UTC
Message-ID: <2361196.ElGaqSPkdT@cayenne>
In-Reply-To: <xmqq1puv55y7.fsf@gitster.g>

On Tuesday, 18 March 2025 05:16:32 CET Junio C Hamano wrote:

> Jean-Noël AVILA <jn.avila@free.fr> writes:
> > For the GNUism, the tests on MacOS and Windows by gitgitgadget passed. But

Show 16 quoted lines

> > get your point and will reroll.
> 
> Is there a good test in our test suite that validates the output of
> this script?  I had an impression that even if the regexp match by
> this grep were a bit off, the only end-user visible effect of such a
> breakage is that some entries from config_name_list[] may be missing
> when "git help --config-for-completion" is called, but I do not
> think of any sensible way to notice that some entries are missing or
> extra entries exist in the output.  So unless the regexp is broken
> so badly that makes the resulting config-list.h syntactically
> incorrect, it is unlikely that our test suite would catch anything,
> I suspect.
> 
> If I deliberately break the regexp (this is before your patch), it
> does not seem to break t0012 (which uses --config-for-completion).
>

I noticed the bug when working with git-branch's doc, because it broke t9902 which specifically tests completion for 'git config get br' and could no longer find the 'branch.' So the tests have eventually found the regression when the formatting went a little more widespread.

As for a way to validate the content of the script, I can only think of committing the config-list.h and checking when the contents diverge.