From: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail•com>
To: "James Bottomley" <James.Bottomley@hansenpartnership•com>,
git@vger•kernel.org
Subject: Re: [PATCH 0/3] add a message-id header to git
Date: Thu, 16 Oct 2025 23:50:25 +0200 [thread overview]
Message-ID: <2464e11c-32b4-4372-90b4-9a6302390e3d@app.fastmail.com> (raw)
In-Reply-To: <20251016185758.21996-1-James.Bottomley@HansenPartnership.com>
On Thu, Oct 16, 2025, at 20:57, James Bottomley wrote:
> There has been some debate in the kernel community about how to link
> commits back to email, which is the basis of a lot of scripting we do
>
> https://lore.kernel.org/ksummit/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/
In that email:
JB> There has been a lot of discussion on the tooling list about how the
JB> loss of link trailers has updated both tooling and triaging issues.
I know of a recent[1] negative opinion about `Link`:
LT> It's not that it isn't "useful to me". It's that it HURTS, and it's
LT> entirely redundant.
LT>
LT> It literally wastes my time. Yes, I have the option to ignore them,
LT> but then I ignore potentially *good* links.
But has there been a decision that they are going away? Do you have a
link to that discussion? Just curious to know more. :)
[1]: https://lore.kernel.org/all/CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com/
You might know that the Git project tracks Message-ID for all commits in
`refs/notes/amlog`. This is straightforward when only the maintainer
applies emails. And up until three hours ago I thought it couldn’t work
beyond on person.
But maybe it could?
1. Everyone who wants to makes or shares a hook to add the Message-ID
2. (and maybe try to upstream a built-in way; this would be simpler to
upstream than a new commit header)
3. Push out the notes ref along with all the other refs
4. The tooling (programs) fetch and merge all of them (from the repos
they know about)
5. With only a collection of remotes that run a hook to add a line to
each incoming commit: the tools can merge all repos since people will
not apply a patch and get a hash collision with someone somewhere
else
6. (“the tools” here since you seem to focus on CI or general tooling)
7. Consumers can fetch this note and have all known mappings
Would this work among nice, cooperating individuals? (That don’t try to
confuse the tooling by notes for commits that already exist in other
repos. For some reason.)
A more careful/structured implementation could also check that the
incoming notes are all (1) only additions, (2) one-line notes, (3) only
annotate commits that the notes-committer has committed (note committer
and commit committer are the same...). But I guess for (3) to be
meaningful you have to manually map repositories to committers.
E.g. repository for Bob may only annotate commits by himself. Or you
can sign the note commits if that is necessary.
Related sub-discussion on the linked thread:
https://lore.kernel.org/ksummit/68ee73dcd10ee_2f89910075@dwillia2-mobl4.notmuch/
On the one hand, pushing and fetching notes does not necessarily sound
like it would fit in an email workflow (*too* integrated with git(1)?).
But your reply here does not mention that kind of objection so I will
soldier on:
https://lore.kernel.org/ksummit/146639e2bc8b5327f57e4297f5a0fcfd3c86d95c.camel@HansenPartnership.com/
JB> I think part of the problem with notes is they're designed not to be
JB> shared.
They aren’t designed to not to be shared, but you are getting at a real
usability downside for individuals. They are “designed” to be hard to
consume/fetch in setups where every single user needs to set up a
refspec in order to fetch them for them to be useful.
But you seem to focus on tooling. For tooling they shouldn’t be any
harder to set up than anything else.
So yeah the downside is for individuals who just want to be able to
opt-in to pretty-print the Message-IDs; they would have to set up a
refspec to get the Message-IDs, just like they do here in Git.
They don’t get it for free from the Git commit object itself.
JB> So there are lots of diverse internal uses for notes that
JB> aren't just the annotations you're thinking of here, so when I push to
JB> a notes tree, I'd likely have to filter and when I pull from it I
JB> wouldn't necessarily want everyone else's notes ... it's like when you
JB> forget to add --no-tags to a pull from someone else's tree and you get
JB> a load of their internal tags that contaminates your internal tag pool.
You get all the blobs for the notes. They take up disk space but they
don’t pollute things beyond that.
JB> Yes, but not all subsystems would care about everything even in this
JB> notes driven annotations model ... so you either have to have filter on
JB> pull or strict rules about what goes in, which then causes issues with
JB> local notes uses.
With one blessed notes namespace for Message-IDs, where’s the potential
conflict? Those who care can fetch.
See previous paragraphs about merging notes across repositories.
With all that naively said: note objections by Konstantin Ryabitsev.
https://lore.kernel.org/ksummit/20251015-versed-active-silkworm-bb87bd@lemur/
>
> However, this problem is one that goes beyond the kernel, so having
Are there examples of projects where this is a pressing need? I would
imagine it is not for smaller email-based projects.
I’m asking because it is good to be specific in the cover letter for a
major change. More than just stating that other cases exist.
>[snip]
next prev parent reply other threads:[~2025-10-16 21:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-16 18:57 [PATCH 0/3] add a message-id header to git James Bottomley
2025-10-16 18:57 ` [PATCH 1/3] mailinfo.c: always collect the message-id James Bottomley
2025-10-16 18:57 ` [PATCH 2/3] builtin/am.c: add a message-id commit header James Bottomley
2025-10-16 22:41 ` brian m. carlson
2025-10-16 18:57 ` [PATCH 3/3] t4150-am: add a test for message-id header collection James Bottomley
2025-10-16 19:26 ` [PATCH 0/3] add a message-id header to git Kristoffer Haugsbakk
2025-10-16 20:10 ` James Bottomley
2025-10-16 20:31 ` Kristoffer Haugsbakk
2025-10-16 20:32 ` Junio C Hamano
2025-10-16 21:00 ` James Bottomley
2025-10-16 21:18 ` Junio C Hamano
2025-10-16 21:28 ` Kristoffer Haugsbakk
2025-10-16 21:50 ` Kristoffer Haugsbakk [this message]
2025-10-16 22:15 ` Junio C Hamano
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=2464e11c-32b4-4372-90b4-9a6302390e3d@app.fastmail.com \
--to=kristofferhaugsbakk@fastmail$(echo .)com \
--cc=James.Bottomley@hansenpartnership$(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