Re: Replacing Link trailers

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

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.

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.

E.g. if a patch is merged by a submaintainer:

    From: somebot: <...>
    Subject: commit annotation for abcd...7890
    X-For-Commit-ID: abcd...7890
    X-For-Patch-ID: bcde....8901
    References: <some@message-id>
    [other headers like Date, Message-ID, etc]

    ---
    source: pub/scm/linux/kernel/git/subsystem/linux
    link: https://patch.msgid.link/some@message-id
    type: merge
    description |
                Merged by somemaintainer@kernel.org

If it is then merged into mainline:
    
    From: somebot: <...>
    Subject: commit annotation for abcd...7890
    X-For-Commit-ID: abcd...7890
    X-For-Patch-ID: bcde....8901
    References: <some@message-id>
    [other headers like Date, Message-ID, etc]

    ---
    source: pub/scm/linux/kernel/git/subsystem/linux
    link: https://patch.msgid.link/some@message-id
    type: merge
    description |
                Merged by torvalds@linuxfoundation.org

If it is then mentioned in a bug report:

    From: SomeOtherBot <...>
    Subject: commit annotation for abcd...7890
    X-For-Commit-ID: abcd...7890
    [other headers like Date, Message-ID, etc]

    ---
    source: https://bugzilla.kernel.org/bug/12345
    link: https://bugzilla.kernel.org/bug/12345/comment1
    type: bug
    description: |
                 Mentioned in bug 12345 comment 1 as possible source of
                 data corruption in frobfs under high loads.

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.

-K