From: Kristoffer Haugsbakk Date: Thu, 16 Oct 2025 21:50:25 GMT Subject: Re: [PATCH 0/3] add a message-id header to git Message-ID: <2464e11c-32b4-4372-90b4-9a6302390e3d@app.fastmail.com> 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]