Re: [PATCH v3 4/4] notes: support an external command to display notes

[Johannes Sixt <j6t@kdbg.org>]

Am 23.05.26 um 12:38 schrieb Siddh Raman Pant:
> git notes is a very very helpful feature to show user-supplied
> information about a commit alongside its message transparently.
> 
> For distributed teams working on large git repos (huge number of
> branches/refs, files, etc.) and using the notes feature to mark
> information on git commits, the problem is often not that two users
> update the same note object at the same time. It is that the local
> notes state used while reading history can be stale.
> 
> In kernel work, the same logical upstream fix can appear as different
> commit objects across many downstream branches, such as the stable
> branches and vendor-specific branches (based on which the released
> kernel is actually built). Different developers may be working on those
> branches in parallel, and a review decision recorded for one backport
> is useful context for the others.
> 
> Today, seeing that decision in ordinary history output requires first
> synchronizing the local notes ref, and then interpreting those notes
> for the branch being inspected. The latter step is workflow-specific
> and can be cheap, but keeping the local notes state fresh enough can be
> expensive in a large kernel repository with a large shared notes
> history (and if we are to extrapolate, a slow git server conn/ops can
> be a factor too).
> 
> This TOCTOU problem exacerbates on scale (rapid updates, more devs,
> larger repos, more git server traffic, etc).
> 
> One solution to this is to move the freshness policy out of git so that
> it is someone else's problem. We can have a realtime fetch or faster
> updation via external helper means. But unfortunately we lose the
> coherence in the display of information, and so the user would end up
> reinventing git log in his quest to have same workflow.

You are presenting one solution here. But a more obvious solution would
have been to make Git's notes implementation capable enough to keep up
with the volume of notes that are produced by your team.

Another solution would be to track the information outside of Git notes
entirely, similar to how pull requests, issues, reviews, and
conversations are tracked by Git hosters in databases outside of Git.

> Let's add support for notes.externalCommand, a protected-configuration
> command that git runs as a long-lived helper when displaying notes. git
> sends commit IDs to the helper and displays any returned text through
> the existing notes formatting path. This keeps presentation in git
> while letting the helper decide how fresh note text is obtained.

To my eyes, this looks like an overengineered solution that helps one
user of a niche feature of Git.

-- Hannes