Re: [PATCH 7/9] notes: support an external command to display notes

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: May 21, 2026, 01:12 UTC
Message-ID: <ag5b4O7-k-3QBR4W@fruit.crustytoothpaste.net>
In-Reply-To: <9619077369f1a567bd505b1de1e4f672a5cd1950.1779207350.git.siddh.raman.pant@oracle.com>

On 2026-05-19 at 16:30:36, Siddh Raman Pant wrote:

Show 27 quoted lines

> 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, a TOCTOU race can happen due to very
> large size of the repo and notes ref:
> 	- Person A updates a note for commit X.
> 	- Person A pushes the notes but it takes some time.
> 	- Person B fetches notes and doesn't find the updated note.
> 	- Person B can come to know of it only when he overwrites it
> 	  and encounters a push failure.
> 
> This problem excaberates on scale.
> 
> One solution to this is a realtime fetch or faster updation via
> external means, but unfortunately we lose the coherence in the
> display of information, and the user would end up reinventing
> git log.
> 
> So let's add support for an external command to display the notes.
> 
> We split the addition of documentation and tests from this commit for
> easier review. The new help text added in Documentation/ in the next
> commit should make the usage clear.
> 
> Assisted-by: Codex:gpt-5.5-xhigh-fast

Just a question here: was this written in whole or in part by Codex, or was it just used as a reference to ask questions? I ask because the style of notes-external.c differs quite a bit from the style we use (for one, the horizontal rule comments) and we have this in SubmittingPatches:

    The Developer's Certificate of Origin requires contributors to certify
    that they know the origin of their contributions to the project and
    that they have the right to submit it under the project's license.
    It's not yet clear that this can be legally satisfied when submitting
    significant amount of content that has been generated by AI tools.

    [...]

    To avoid these issues, we will reject anything that looks AI
    generated, that sounds overly formal or bloated, that looks like AI
    slop, that looks good on the surface but makes no sense, or that
    senders don’t understand or cannot explain.

I'll note that it also has a lot of global variables, which are common in the codebase but we're trying to move away from, and it's more verbose in commenting than we'd normally see elsewhere in the codebase.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA