git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "D. Ben Knoble via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  "D. Ben Knoble" <ben.knoble+github@gmail.com>
Subject: Re: [PATCH] grep: document negated line-number, column long options
Date: Thu, 16 Jan 2025 14:54:19 -0800	[thread overview]
Message-ID: <xmqqy0zanzdw.fsf@gitster.g> (raw)
In-Reply-To: <pull.1878.git.git.1737066042014.gitgitgadget@gmail.com> (D. Ben Knoble via GitGitGadget's message of "Thu, 16 Jan 2025 22:20:41 +0000")

"D. Ben Knoble via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: "D. Ben Knoble" <ben.knoble+github@gmail.com>
>
> I set grep.lineNumber and grep.column on in my user .gitconfig;
> sometimes, when I script over the results from `git grep`, I want no
> prefixes, only a filename prefix, or only the matched text. I usually
> comment out the relevant config sections or use `git -c` to tweak them for
> a single run---why? Because `git help grep` doesn't mention they can be
> disabled any other way!

While I am somewhat sympathetic, I'd prefer to see it done in a more
centralized way, so that people understand that *any* Boolean option
and associated configuratrion can be negated by prefixing "--no-" to
the base option, instead of having to learn "Ah, today I learned
that --line-number can be negated with --no-line-number thanks to
this patch."

>  --line-number::
>  	Prefix the line number to matching lines.
>  
> +--no-line-number::
> +	Turn off line number prefixes, even when the configuration file or a
> +	previous option requests them.

So, this is not quite welcome for two reasons.

 - We do not want to see us keep repeating "configuration file" for
   any negatable option, as it is common to all command line options
   and associated configuration knob that the command line option
   trumps the configuration.

 - We do not want to see us keep repeating the substantial part of
   the body of the base option by adding a separate entry for a
   corresponding variant with "--no-".

Even though an approach to centrally teach people that they can
negate a Boolean option "--opt" by saying "--no-opt", and thatn they
can negate a configured setting with a command line option is
desirable, for such an approach to work, the documentation must
somehow signal which option is Boolean.

The way we do so is by doing something like this.

$ git grep -e '^--\[no-\]' Documentation/

An example entry (this is from blame-options.txt) looks like this.

    --[no-]progress::
            Progress status is reported on the standard error stream
            by default when it is attached to a terminal. This flag
            enables progress reporting even if not attached to a
            terminal. Can't use `--progress` together with `--porcelain`
            or `--incremental`.

As nobody complains that "I cannot understand what --no-progress,
which is described in the above, means", there must be a central
place where we describe this convention ("git help cli" talks about
negating options).

So I suspect you'd only need to do something like this

    ---line-number::
    +--[no-]line-number::
	    Prefix the line number ...

in your patch, without doing anything else.

Thanks.

  reply	other threads:[~2025-01-16 22:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-16 22:20 [PATCH] grep: document negated line-number, column long options D. Ben Knoble via GitGitGadget
2025-01-16 22:54 ` Junio C Hamano [this message]
2025-01-17  0:29   ` Junio C Hamano
2025-01-17  2:05     ` [PATCH v2] gitcli: document that command line trumps config and env Junio C Hamano
2025-01-17  2:41       ` brian m. carlson
2025-01-17 18:09         ` Junio C Hamano
2025-01-17  3:14     ` [PATCH] grep: document negated line-number, column long options Eric Sunshine
2025-01-19 23:17   ` D. Ben Knoble
2025-01-21 20:51     ` 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=xmqqy0zanzdw.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ben.knoble+github@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.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 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 NNTP newsgroup(s).