git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / 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:34 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

  List information: http://vger.kernel.org/majordomo-info.html

* 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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).