Re: [PATCH v2] grep: add configuration variables for --heading

From: Simon Ser <contact@emersion.fr>
Date: Jun 8, 2020, 10:22 UTC
Message-ID: <2lg0C_0k4SnWqhB0oW3wGE6eixtc_ZT5GgZJFzH8XC6g5dJXmSGGnrV9uZVT4QIOG9Sjc7yuLOR_v5kwGIV1hnMSojXinNG16G3tOOMg-Fc=@emersion.fr>
In-Reply-To: <xmqqeer5mina.fsf@gitster.c.googlers.com>

On Wednesday, May 27, 2020 6:45 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 7 quoted lines

> Naturally it follows that a command-line option
>
> $ git config grep.heading yes
> $ git grep --no-heading -e pattern
>
> is a way to countermand the configured default per invocation
> basis.

Is see where you're getting at, but this is missing for a handful of options, like grep.lineNumber and grep.column. I'd rather not create an inconsistency here.

Show 16 quoted lines

> When writing new tests, we often get too excited and stop at showing
> off how well the shiny new feature works, but we should make sure
> that we test the "negative" case, too, i.e. that the "feature" can
> be disabled when the user does not want to trigger it, and that the
> "feature" notices incorrect invocations and fails appropriately.
>
> E.g.
>
> git -c grep.heading=yes grep --no-heading ...
>
> should not leave the opt->heading true, and
>
> git -c grep.heading=nonsense grep ...
>
> should fail, saying "grep.heading must be a bool" (or something
> along that line).

Note, these new tests are only required if --no-heading is added to the patch.