From: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail•com>
To: git@vger•kernel.org
Subject: trailers: --only-trailers normalizes URLs to trailers
Date: Thu, 04 Jun 2026 23:27:51 +0200 [thread overview]
Message-ID: <ae4a32e7-bacb-4c88-b2a0-5aeaff60b904@app.fastmail.com> (raw)
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.
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
Ran what is the equivalent of
git interpret-trailers --only-trailers
With
git log --format="%(trailers:only)"
> What did you expect to happen? (Expected behavior)
For URLs like https://www.digsm.xyz/ to be left intact.
(Well, did I expect that? It follows from the discussed behavior...)
> What happened instead? (Actual behavior)
URLs on a line by themselves in eligible trailer blocks get
normalized/canonicalized to a “trailer” with key e.g. `https`:
https: //www.digsm.xyz/
> 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: //...
Maybe a C-style comment?
https: // I changed my mind about providing a URL here.
This comment is a placeholder.
Comment: // But next up we have a URL
https: https://protocoltwiceover.net
And this is where my imagination ends.
Just special-casing `https` would go a long way.
> Anything else you want to add:
Yes, after this [System Info] part.
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.54.0
cpu: x86_64
built from commit: 94f057755b7941b321fd11fec1b2e3ca5313a4e0
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
rust: disabled
gettext: enabled
libcurl: 7.81.0
OpenSSL: OpenSSL 3.0.2 15 Mar 2022
zlib: 1.2.11
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
uname: Linux 6.8.0-117-generic #117~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu May 7 22:17:46 UTC x86_64
compiler info: gnuc: 11.4
libc info: glibc: 2.35
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
commit-msg
post-applypatch
post-commit
sendemail-validate
***
That things like `--format='%(trailers:only)'` normalize trailers is
known and has been discussed before.[1] There’s been discussion around
the key capitalization and prefix normalization. But this is not about
that. This is just about normalizing the separator part.
🔗 1: https://lore.kernel.org/git/87blk0rjob.fsf@0x63.nu/
One design goal for trailers (either by implementers or reviewers or both)
has been to avoid false positives.[2] That meant trying to avoid
detecting trailers that were not intended. For example:
Everything was better in the past. Let me not even start on this
rant: it is not good for my blood pressure.
This will not be picked up as a trailer block unless `rant` is configured
as a trailer key.
† 2: See e.g. Jonathan Tan’s series about among other things adding the
25% rule
https://lore.kernel.org/git/xmqq7f96sa9i.fsf@gitster.mtv.corp.google.com/
But that’s pretty innocuous. Just a misplaced rant. The topic of this
bug report is not a big deal either, but it is:
1. Structured data that gets mangled in this normalize mode
2. That can naturally go at the end of the message on its own line
And these two points are very relevant for people who never use
trailers. Or, wait. I guess it isn’t if they don’t use trailers and thus
will never normalize them. But it is relevant if they work on a project
where someone else does that.
IN INTENDED TRAILER BLOCKS [3]
And then there are things that can go wrong if you intend to write trailer blocks:
1. “Non-trailer lines” that are URLs get normalized as trailers (NTL for
short)
2. User error line wrapping turns one trailer into an empty trailer plus
a `https` trailer (LW for short)
3. Normalizing trailers along the way (as in patches in flight or
something) introduces this strange lossiness (NL for short)
I did (2) (LW for short) four years ago it seems:
See:
https://digsm.yxz/blog/important-context/?bigtechtracker=86b0c5a1e2b73b08fd54c727f4458649ed9fe3ad1b6e8ac9460c070113509a1e
† 3: Are all-caps titles good or bad? Let me know.
IN THE LINUX KERNEL
There are some hits for the `http` and `https` trailers when trailers
are normalized. The baseline:
$ git log --extended-regexp --grep='https?: //' --oneline | wc -l
12
With normalization:
$ git log --format='%(trailers:only)' |
grep --extended-regexp '^https?: //' | wc -l
245
Note that I have no idea how the Linux Kernel is run. But I don’t
imagine that there are uses for `https: //...` trailers.
And trailer usage is complicated. There are for example on-purpose
indented `Link` “trailers”, presumably for the purpose of *excluding*
them as `Link` trailers. See:
commit d80a9cb1a64ab9c817b6262c7e4e433b6a3581a0
<body>
[ljs@kernel•org: avoid bisection hazard]
Link: https://lkml.kernel.org/r/d0cc6161-77a4-42ba-a411-96c23c78df1b@lucifer.local
Link: https://lkml.kernel.org/r/c2be872d64ef9573b80727d9ab5446cf002f17b5.1774029655.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel•org>
[MORE BELOW]
Is that indented link for that `[]` comment? I dunno.
But what’s the main topic here are intended non-trailer lines which are
URLs that get treated as trailers (NTL). Like this invented example:
Reported-by: ...
https://digsm.xyz/?avastvirus=5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03
Signed-off-by: ...
Or this real example where the URLs are clearly part of a “comment”
non-trailer run.
8236fc613d44e59f6736d6c3e9efffaf26ab7f00
Signed-off-by: Shuai Xue <xueshuai@linux•alibaba.com>
[bhelgaas: squash fixes:
https://lore.kernel.org/r/20260108013956.14351-2-bagasdotme@gmail.com
https://lore.kernel.org/r/20260108013956.14351-3-bagasdotme@gmail.com]
Signed-off-by: Bjorn Helgaas <bhelgaas@google•com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux•intel.com>
Link: https://patch.msgid.link/20251210132907.58799-4-xueshuai@linux.alibaba.com
(These are shown as they are written in the commit message. Normalizing
the messages would create `https` trailers.)
Here are examples of line-wrapping mistake commits (LW) for `Link`,
`Closes`, or `Fixes` (sometimes these point to bug URLs and not
commits):
5bd97f5c5f241a5610c4412d1b93995a26241f81
Link: https://patch.msgid.link/20260216-work-xattr-socket-v1-4-c2efa4f74cb7@kernel.org
Link:
https://lore.kernel.org/3cnmtqmakpbb2uwhenrj7kdqu3uefykiykjllgfbtpkiwhaa4s@sghkevv7jned [1]
Acked-by: Darrick J. Wong <djwong@kernel•org>
Reviewed-by: Jan Kara <jack@suse•cz>
Signed-off-by: Christian Brauner <brauner@kernel•org>
and:
• 24abe1f238e7d7ac56be6374c52a3c13dab84f69
• 27e21516914dc130a79aa895a5a26e18f0213a5a
• be3536a4bdda53ff5a91b7e542b167d12bddb317
Finally there is this commit which has a trailer in the commit message
itself with the key `https` (NL).
commit 496c0c4c53bbe1bad97e82cd12103df61a6e459d
...
...
net: wan: fsl_ucc_hdlc: free tx_skbuff in uhdlc_memclean
<body>
https: //sashiko.dev/#/patchset/20260429114208.941011-1-holger.brunck%40hitachienergy.com
Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy•com>
Link: https://patch.msgid.link/20260507155332.3452319-1-holger.brunck@hitachienergy.com
Signed-off-by: Jakub Kicinski <kuba@kernel•org>
How could this have happened? Follow the patch-id link.
https://patch.msgid.link/20260507155332.3452319-1-holger.brunck@hitachienergy.com
https://sashiko.dev/#/patchset/20260429114208.941011-1-holger.brunck%40hitachienergy.com
Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy•com>
So it was just a non-trailer URL line as this person submitted it. But
presumably the person who applied it put the message through a round of
normalization.
Cheers, good night
--
Kristoffer
reply other threads:[~2026-06-04 21:28 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=ae4a32e7-bacb-4c88-b2a0-5aeaff60b904@app.fastmail.com \
--to=kristofferhaugsbakk@fastmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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