From: Christian Couder <email@example.com>
To: Junio C Hamano <firstname.lastname@example.org>
Cc: git <email@example.com>, Anders Waldenborg <firstname.lastname@example.org>,
Jeff King <email@example.com>,
Jonathan Tan <firstname.lastname@example.org>
Subject: Re: Questions about trailer configuration semantics
Date: Mon, 27 Jul 2020 20:37:26 +0200 [thread overview]
Message-ID: <CAP8UFD1XV_jN10yOc2o4=5PtPcvT-RbxhY1H3swZz2r4g-Uzkw@mail.gmail.com> (raw)
[Adding Peff and Jonathan in Cc as they know also about this area of the code]
On Mon, Jul 27, 2020 at 7:18 PM Junio C Hamano <email@example.com> wrote:
> [Redirecting it to the resident expert of the trailers]
> Anders Waldenborg <firstname.lastname@example.org> writes:
> > I noticed some undocumented and (at least to me) surprising behavior in
> > trailers.c.
> > When configuring a value in trailer.<token>.key it causes the trailer to
> > be normalized to that in "git interpret-trailers --parse".
> > E.g:
> > $ printf '\naCKed: Zz\n' | \
> > git -c 'trailer.Acked.key=Acked' interpret-trailers --parse
> > will emit: "Acked: Zz"
Yeah, I think that's nice, as it can make sure that the key appears in
the same way. It's true that it would be better if it would be
> > but only if "key" is used, other config options doesn't cause it to be
> > normalized.
> > E.g:
> > $ printf '\naCKed: Zz\n' | \
> > git -c 'trailer.Acked.ifmissing=doNothing' interpret-trailers --parse
> > will emit: "aCKed: Zz" (still lowercase a and uppercase CK)
Yeah, in this case we are not sure if "Acked" or "aCKed" is the right
way to spell it.
> > Then there is the replacement by config "trailer.fix.key=Fixes" which
> > expands "fix" to "Fixes". This happens when using "--trailer 'fix = 123'"
> > which seems to be expected and useful behavior (albeit a bit unclear in
> > documentation). But it also happens when parsing incoming trailers, e.g
> > with that config
> > $ printf "\nFix: 1\n" | git interpret-trailers --parse
> > will emit: "Fixes: 1"
Yeah, I think it allows for shortcuts and can help with standardizing
the keys in commit messages.
> > (token_from_item prefers order .key, incoming token, .name)
> > The most surprising thing is that it uses prefix matching when finding
> > they key in configuration. If I have "trailer.reviewed.key=Reviewed-By"
> > it is possible to just '--trailer r=XYZ' and it will find the
> > reviewed-by trailer as "r" is a prefix of reviewedby. This also applies
> > to the "--parse".
Yeah, that's also for shortcuts and standardization.
> > This in makes it impossible to have trailer keys that
> > are prefix of each other (e.g: "Acked", "Acked-Tests", "Acked-Docs") if
> > there is multiple matching in configuration it will just pick the one
> > that happens to come first.
That's a downside of the above. I agree that it might seem strange or
bad. Perhaps an option could be added to implement a strict matching,
if people really want it.
Also if you configure trailers in the "Acked", "Acked-Tests",
"Acked-Docs" order, then any common prefix will pick "Acked" which
could be considered ok in my opinion.
> > (token_matches_item uses strncasecmp with token length)
> > I guess these are the questions for the above observations:
> > * Should normalization of spelling happen at all?
Yes, I think it can help.
> > * If so should it only happen when there is a .key config?
Yes, it can help too if that only happens when there is a .key config.
> > * Should replacement to what is in .key happen also in --parse mode, or
> > only for "--trailer"
I think it's more consistent if it happens in both --parse and
--trailer mode. I didn't implement --parse though.
> > * The prefix matching gotta be a bug, right?
No, it's a feature ;-) Seriously I agree that this could be seen as a
downside, but I think it can be understood that the convenience is
worth it. And in case someone is really annoyed by this, then adding
an option for strict matching should not be very difficult.
> > Here is a patch to the tests showing these things.
Thanks for the patch! I would be ok to add such a patch to the test
suite if it was sent like a regular patch (so with a commit message, a
Signed-off-by: and so on) to the mailing list. While at it some
documentation of the related behavior would also be very nice.
next prev parent reply other threads:[~2020-07-27 18:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-27 16:45 Questions about trailer configuration semantics Anders Waldenborg
2020-07-27 17:18 ` Junio C Hamano
2020-07-27 18:37 ` Christian Couder [this message]
2020-07-27 19:40 ` Jeff King
2020-07-27 22:57 ` Anders Waldenborg
2020-07-27 23:42 ` Jeff King
2020-07-27 20:11 ` Junio C Hamano
2020-07-27 22:17 ` Anders Waldenborg
2020-07-27 23:05 ` Junio C Hamano
2020-07-28 0:01 ` Anders Waldenborg
2020-07-27 21:41 ` Anders Waldenborg
2020-07-27 22:53 ` Junio C Hamano
2020-07-27 23:17 ` Anders Waldenborg
2020-07-28 7:07 ` Christian Couder
2020-07-28 15:41 ` Jeff King
2020-07-28 16:40 ` Junio C Hamano
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:
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 \
* 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
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).