From: Linus Arver <linusa@google.com>
To: Junio C Hamano <gitster@pobox.com>,
Linus Arver via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/5] trailer: add tests to check defaulting behavior with --no-* flags
Date: Sun, 06 Aug 2023 22:28:43 -0700 [thread overview]
Message-ID: <owlyfs4vbeus.fsf@fine.c.googlers.com> (raw)
In-Reply-To: <xmqqjzu7irhw.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> "Linus Arver via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> @@ -114,8 +114,10 @@ OPTIONS
>> Specify where all new trailers will be added. A setting
>> provided with '--where' overrides all configuration variables
>
> Obviously this is not a new issue, but "all configuration variables"
> is misleading (the same comment applies to the description of the
> "--[no-]if-exists" and the "--[no-]if-missing" options).
Agreed.
> If I am reading the code correctly, --where=value overrides the
> trailer.where variable and nothing else, and --no-where stops the
> overriding of the trailer.where variable. Ditto for the other two
> with their relevant configuration variables.
That is also my understanding. Will update to remove the "all" wording.
On a separate note, I've realized there are more fixes to be done in
this area (as I get more familiar with the codebase). For example, we
have the following language in builtin/interpret-trailers.c inside
cmd_interpret_trailers():
OPT_BOOL(0, "only-input", &opts.only_input, N_("do not apply config rules")),
which should be fixed in similar style to what you suggested above,
probably with:
OPT_BOOL(0, "only-input", &opts.only_input, N_("do not apply trailer.* configuration variables")),
When I reroll, I will include these additional fixes so expect the patch
series to grow (probably ~12 patches instead of the ~5).
One more thing. I think the documentation
(Documentation/git-interpret-trailers.txt) uses the word "<token>" in
two different ways. For example, if we have in the input
subject line
body text
Acked-by: Foo
the docs treat the word "Acked-by:" as the <token>. However, it defines
the relevant configuration section like this:
trailer.<token>.key::
This `key` will be used instead of <token> in the trailer. At
the end of this key, a separator can appear and then some
space characters. By default the only valid separator is ':',
but this can be changed using the `trailer.separators` config
variable.
+
If there is a separator, then the key will be used instead of both the
<token> and the default separator when adding the trailer.
So if I configure this like
git config trailer.ack.key "Acked-by" &&
the <token> is both the longer-form "Acked-by:" (per the meaning so far
in the doc) but also the shorter string "ack" per the
"trailer.<token>.key" configuration section syntax. This secondary
meaning is repeated again in the very start of the doc when we define
the --trailer option syntax as
SYNOPSIS
--------
[verse]
'git interpret-trailers' [--in-place] [--trim-empty]
[(--trailer <token>[(=|:)<value>])...]
[--parse] [<file>...]
because the <token> here could be (using the example above) either
"Acked-by" (as in "--trailer=Acked-by:...") if we did not configure
"trailer.ack.key", or just "ack" (as in "--trailer=ack:...") if we did
configure it. These two scenarios would give identical "Acked-by: ..."
output.
This is confusing and I don't like how we overload this "token" word
(not to mention we already have the word "key" which we don't really use
much in the docs).
I am inclined to replace most uses of the word "<token>" with "<key>"
while leaving the "trailer.<token>.key" configuration syntax intact.
This will result in a large diff but I think the removal of the double
meaning is worth it, and will include this fix also in the next reroll.
The main reason I bring this up is because this means also having to
update our funciton names like "token_len_without_separator" in
trailer.c, to be "key_len_without_separator" if we want the nomenclature
in the trailer.c internals to be consistent with the (updated)
user-facing docs. I am not sure whether we want to do this as part of
the same reroll, or if we should leave it as #leftoverbits for a future
series.
next prev parent reply other threads:[~2023-08-07 5:28 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-05 4:45 [PATCH 0/5] Fixes to trailer test script, help text, and documentation Linus Arver via GitGitGadget
2023-08-05 4:45 ` [PATCH 1/5] trailer tests: make test cases self-contained Linus Arver via GitGitGadget
2023-08-07 5:50 ` Linus Arver
2023-08-05 4:45 ` [PATCH 2/5] trailer test description: this tests --where=after, not --where=before Linus Arver via GitGitGadget
2023-08-05 4:45 ` [PATCH 3/5] trailer: add tests to check defaulting behavior with --no-* flags Linus Arver via GitGitGadget
2023-08-07 1:13 ` Junio C Hamano
2023-08-07 5:28 ` Linus Arver [this message]
2023-08-07 5:37 ` Linus Arver
2023-08-07 6:35 ` Linus Arver
2023-08-07 15:53 ` Junio C Hamano
2023-08-05 4:45 ` [PATCH 4/5] trailer: trailer location is a place, not an action Linus Arver via GitGitGadget
2023-08-05 4:45 ` [PATCH 5/5] trailer --no-divider help: describe usual "---" meaning Linus Arver via GitGitGadget
2023-08-10 21:17 ` [PATCH v2 00/13] Fixes to trailer test script, help text, and documentation Linus Arver via GitGitGadget
2023-08-10 21:17 ` [PATCH v2 01/13] trailer tests: make test cases self-contained Linus Arver via GitGitGadget
2023-08-10 21:17 ` [PATCH v2 02/13] trailer test description: this tests --where=after, not --where=before Linus Arver via GitGitGadget
2023-08-10 21:17 ` [PATCH v2 03/13] trailer: add tests to check defaulting behavior with --no-* flags Linus Arver via GitGitGadget
2023-08-10 21:17 ` [PATCH v2 04/13] trailer doc: narrow down scope of --where and related flags Linus Arver via GitGitGadget
2023-08-10 21:17 ` [PATCH v2 05/13] trailer: trailer location is a place, not an action Linus Arver via GitGitGadget
2023-08-10 21:17 ` [PATCH v2 06/13] trailer --no-divider help: describe usual "---" meaning Linus Arver via GitGitGadget
2023-08-10 21:17 ` [PATCH v2 07/13] trailer --parse help: expose aliased options Linus Arver via GitGitGadget
2023-08-10 21:17 ` [PATCH v2 08/13] trailer --only-input: prefer "configuration variables" over "rules" Linus Arver via GitGitGadget
2023-08-10 21:17 ` [PATCH v2 09/13] trailer --parse docs: add explanation for its usefulness Linus Arver via GitGitGadget
2023-08-10 21:18 ` [PATCH v2 10/13] trailer --unfold help: prefer "reformat" over "join" Linus Arver via GitGitGadget
2023-08-10 21:18 ` [PATCH v2 11/13] trailer doc: emphasize the effect of configuration variables Linus Arver via GitGitGadget
2023-08-10 21:18 ` [PATCH v2 12/13] trailer doc: separator within key suppresses default separator Linus Arver via GitGitGadget
2023-08-10 21:18 ` [PATCH v2 13/13] trailer doc: <token> is a <key> or <keyAlias>, not both Linus Arver via GitGitGadget
2023-08-11 1:41 ` [PATCH v2 00/13] Fixes to trailer test script, help text, and documentation Junio C Hamano
2023-08-11 17:38 ` Linus Arver
2023-09-07 22:19 ` [PATCH v3 " Linus Arver via GitGitGadget
2023-09-07 22:19 ` [PATCH v3 01/13] trailer tests: make test cases self-contained Linus Arver via GitGitGadget
2023-09-07 22:19 ` [PATCH v3 02/13] trailer test description: this tests --where=after, not --where=before Linus Arver via GitGitGadget
2023-09-07 22:19 ` [PATCH v3 03/13] trailer: add tests to check defaulting behavior with --no-* flags Linus Arver via GitGitGadget
2023-09-08 21:52 ` Junio C Hamano
2023-09-07 22:20 ` [PATCH v3 04/13] trailer doc: narrow down scope of --where and related flags Linus Arver via GitGitGadget
2023-09-07 22:20 ` [PATCH v3 05/13] trailer: trailer location is a place, not an action Linus Arver via GitGitGadget
2023-09-19 22:13 ` Jonathan Tan
2023-09-07 22:20 ` [PATCH v3 06/13] trailer --no-divider help: describe usual "---" meaning Linus Arver via GitGitGadget
2023-09-08 21:53 ` Junio C Hamano
2023-09-07 22:20 ` [PATCH v3 07/13] trailer --parse help: expose aliased options Linus Arver via GitGitGadget
2023-09-19 22:16 ` Jonathan Tan
2023-09-07 22:20 ` [PATCH v3 08/13] trailer --only-input: prefer "configuration variables" over "rules" Linus Arver via GitGitGadget
2023-09-07 22:20 ` [PATCH v3 09/13] trailer --parse docs: add explanation for its usefulness Linus Arver via GitGitGadget
2023-09-08 21:57 ` Junio C Hamano
2023-09-07 22:20 ` [PATCH v3 10/13] trailer --unfold help: prefer "reformat" over "join" Linus Arver via GitGitGadget
2023-09-07 22:20 ` [PATCH v3 11/13] trailer doc: emphasize the effect of configuration variables Linus Arver via GitGitGadget
2023-09-07 22:20 ` [PATCH v3 12/13] trailer doc: separator within key suppresses default separator Linus Arver via GitGitGadget
2023-09-07 22:20 ` [PATCH v3 13/13] trailer doc: <token> is a <key> or <keyAlias>, not both Linus Arver via GitGitGadget
2023-09-19 22:59 ` Jonathan Tan
2023-09-20 6:48 ` Linus Arver
2023-09-20 15:01 ` Junio C Hamano
2023-09-22 18:26 ` Linus Arver
2023-11-10 6:33 ` Teng Long
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=owlyfs4vbeus.fsf@fine.c.googlers.com \
--to=linusa@google.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--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 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).