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
>
next prev parent 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).