All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Altmanninger <aclopte@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH] grep: clarify what `grep.patternType=default` means
Date: Sun, 5 Dec 2021 14:33:52 +0100	[thread overview]
Message-ID: <20211205133352.ukucgvynpuvypfnn@gmail.com> (raw)
In-Reply-To: <xmqq7dcq62af.fsf@gitster.g>

On Mon, Nov 29, 2021 at 02:10:48PM -0800, Junio C Hamano wrote:
> Back in the days when the "return to the default matching behavior"
> part was written in 84befcd0 (grep: add a grep.patternType
> configuration setting, 2012-08-03), grep.extendedRegexp was the only
> way to configure the behaviour since b22520a3 (grep: allow -E and -n
> to be turned on by default via configuration, 2011-03-30).

The 'the "return to the default matching behavior" part' is a forward
reference, so I tried this instead:

Commit 84befcd0 (grep: add a grep.patternType configuration setting,
2012-08-03) documented that grep.patternType=default falls back to the
"default matching behavior". Prior to that, grep.extendedRegexp was the only
way to configure the matching behavior (since b22520a3 (grep: allow -E and
-n to be turned on by default via configuration, 2011-03-30)).

> 
> It was understandable that we referred to the behaviour that honors

"It was" -> "It is"?

> the older configuration variable as "the default matching"
> behaviour.  It is fairly clear in its log message:

I guess %s/behaviour/behavior/

> 
>     When grep.patternType is set to a value other than "default", the
>     grep.extendedRegexp setting is ignored. The value of "default" restores
>     the current default behavior, including the grep.extendedRegexp
>     behavior.
> 
> But when the paragraph is read in isolation by a new person who is
> not aware of that backstory (which is the synonym for "most users"),
> the "default matching behaviour" can be read as "how 'git grep'
> behaves without any configuration variables or options", which is
> "match the pattern as BRE".
> 
> Clarify what the passage means by elaborating what the phrase
> "default matching behaviour" wanted to mean.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> 
>  * Whether the eventual deprecation of grep.extendedRegexp is a good
>    idea, we'd need something like this to clarify what these two
>    variables are meant to interact with each other first.
> 
>  Documentation/config/grep.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/config/grep.txt b/Documentation/config/grep.txt
> index 44abe45a7c..72f5e03614 100644
> --- a/Documentation/config/grep.txt
> +++ b/Documentation/config/grep.txt
> @@ -8,7 +8,8 @@ grep.patternType::
>  	Set the default matching behavior. Using a value of 'basic', 'extended',
>  	'fixed', or 'perl' will enable the `--basic-regexp`, `--extended-regexp`,
>  	`--fixed-strings`, or `--perl-regexp` option accordingly, while the
> -	value 'default' will return to the default matching behavior.
> +	value 'default' will use the settings of `grep.extendedRegexp` option
> +	to choose between `basic` and `extended`.

Yes, much better.
Maybe "settings" -> "value". Probably subjective but plural sounds weird
since grep.extendedRegexp is just one bit.

Also this introduces a local inconsistency: above we write 'basic' and here `basic`.

>  
>  grep.extendedRegexp::
>  	If set to true, enable `--extended-regexp` option by default. This
> -- 
> 2.34.1-251-g6783e24198
> 

  reply	other threads:[~2021-12-05 13:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-29 22:10 [PATCH] grep: clarify what `grep.patternType=default` means Junio C Hamano
2021-12-05 13:33 ` Johannes Altmanninger [this message]
2021-12-05 20:25   ` Re* " Junio C Hamano
2021-12-05 20:26     ` [PATCH v2] " Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211205133352.ukucgvynpuvypfnn@gmail.com \
    --to=aclopte@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.