Re: Replacing Link trailers

[<dan.j.williams@intel.com>]

Konstantin Ryabitsev wrote:
> On Wed, Oct 15, 2025 at 10:09:33AM -0700, dan.j.williams@intel.com wrote:
> > > So unless we have one big "all the notes merged into one" tree
> > > somewhere
> > 
> > ...circling back to say. Why *not* do this?
> 
> Git notes are fragile, they have important scalability problems (they are all
> just files in a single ref, so if you have a million annotated commits, you
> have a million files split across a bunch of two-letter prefixed dirs), and
> when multiple writers are editing notes, you will have conflicts and merges.
> 
> It's not a great medium for a system that's supposed to be continuously added
> to.

Ack.

> I have pondered this multiple times and my preferred approach would be to have
> a machine-readable feed that can be indexed and searched. To me, it makes
> sense to make it a public-inbox feed that is just RFC-2822 messages, but
> that's obviously because I have a large public-inbox hammer. Our transparency
> feed operates this way:
> 
> https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/1.git/plain/m
> 
> We could have the same approach with commit annotations.

I like it.

[..]
> This is trivial to search for if we're indexing X-For-Commit-ID headers and
> then trivial to parse to get a full "medical history" of a commit. Anyone can
> clone this and run their own analysis on it using heuristic or AI tools.
> 
> This generally goes into my vision of lore as a "message bus" of sorts for
> everything to do with Linux development. It's unwieldy for a human, but we're
> gradually entering into an era where automated agents are able to efficiently
> analyze the firehose and tame it for maintainers. Maybe.

Yeah, and this addresses the other problem with git notes is that they
do not follow commits as they get backported. I.e. I think folks were
using the submission Link: trailer as a persistent cookie.

The main motivations for git notes for me were to restore the ergonomic
experience of reading a commit in gitweb/cgit in the browser and just
clicking over to lore to read the thread, and to help track commit state
relative to mailing list postings over revisions. That can stay local to
a subsystem repo and like you suggest, let a feed handle all the other
forensics folks need.