From: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>
To: "Jeff King" <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: trailers: --only-trailers normalizes URLs to trailers
Date: Wed, 10 Jun 2026 16:21:29 +0200 [thread overview]
Message-ID: <d8f7f827-27da-41fc-af8d-72d383b24fff@app.fastmail.com> (raw)
In-Reply-To: <20260609004340.GF358144@coredump.intra.peff.net>
On Tue, Jun 9, 2026, at 02:43, Jeff King wrote:
> On Thu, Jun 04, 2026 at 11:27:51PM +0200, Kristoffer Haugsbakk wrote:
>
>> The following is a bug that follows straightforwardly from the documented
>> or discussed behavior. In that sense it is not a bug. But it is a bug in
>> the sense that it makes things inconvenient and violates a design goal.
>
> Yeah, though if you'll allow me to nitpick your subject a moment: I
> don't think --only-trailers is really the culprit here. It demonstrates
> the problem because it normalizes the "trailer" it found. But the loose
> trailer matching is the more fundamental issue. For example:
>
>[snip]
Yeah, this is more precise. I focused a ton on the normalized output
because that’s what makes it obvious. But the fundamental problem is
interpreting URLs like trailers.
>
>> > What's different between what you expected and what actually happened?
>>
>> In an ideal world to have some special-casing of URLs so that they are
>> not detected as trailers. Does anyone realistically want trailers like
>> this?:
>>
>> file: //...
>> http: //...
>> https: //...
>
> I could even see those as trailers, if somebody really wanted to allow
> arbitrary values that might just happen to start with "//". But without
> the whitespace after the colon, it is quite questionable.
>
>> Just special-casing `https` would go a long way.
>
> Agreed, though I think a rule like: ":// (with no whitespace)" is not a
> valid separator. Something like this:
Yes, matching on `://` strictly is a better proposal. No need to care
about `http`, `https`, `file`, etc. And both of these would *still* have
to be true for this change to be a false negative w.r.t. the user’s
intentions:
• They really input a trailer that looks like a URL, but it’s not meant
to be a URL
• They really wanted the value to start with `//`
And again I don’t think that is likely to ever happen (with a knock
on wood).
Thanks!
>
> diff --git a/trailer.c b/trailer.c
> index 6d8ec7fa8d..342ed81c78 100644
> --- a/trailer.c
> +++ b/trailer.c
> @@ -635,8 +635,12 @@ static ssize_t find_separator(const char *line,
> const char *separators)
> int whitespace_found = 0;
> const char *c;
> for (c = line; *c; c++) {
> - if (strchr(separators, *c))
> + if (strchr(separators, *c)) {
> + /* special case to avoid accidental URL matches */
> + if (*c == ':' && c[1] == '/' && c[2] == '/')
> + return -1;
> return c - line;
> + }
> if (!whitespace_found && (isalnum(*c) || *c == '-'))
> continue;
> if (c != line && (*c == ' ' || *c == '\t')) {
next prev parent reply other threads:[~2026-06-10 14:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-04 21:27 trailers: --only-trailers normalizes URLs to trailers Kristoffer Haugsbakk
2026-06-09 0:43 ` Jeff King
2026-06-10 14:21 ` Kristoffer Haugsbakk [this message]
2026-06-11 6:56 ` Jeff King
2026-06-11 7:03 ` Kristoffer Haugsbakk
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=d8f7f827-27da-41fc-af8d-72d383b24fff@app.fastmail.com \
--to=kristofferhaugsbakk@fastmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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