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/
James Bottomley
