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.netAnd 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% rulehttps://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
245Note 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