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

From: Siddh Raman Pant <siddh.raman.pant@oracle.com>
Date: May 20, 2026, 06:59 UTC
Message-ID: <aaf25b8c84a51d0a3156af1944ec39b51f764019.camel@oracle.com>
In-Reply-To: <87fr3nq74l.fsf@gitster.g>

On Wed, May 20 2026 at 05:33:54 +0530, Junio C Hamano wrote:

Show 17 quoted lines

> Siddh Raman Pant <siddh.raman.pant@oracle.com> writes:
> 
> > 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.
> 
> It is unclear how we would arrive at "So let's" from the previous
> paragraph.  It is not limited to notes but multiple people updating
> the same thing racing against each other happens all the time in the
> main part of the history, no?  Isn't a better solution for such
> racing situation usually based on a better merge support, I have to
> wonder?

Sorry, I should have been clear.

The issue I meant to describe is not primarily about two people updating the same note object at the same time.

The workflow I have in mind is different. 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).

That is the synchronization problem I was trying to describe: not that Git should solve all concurrent note updates, but that users can be looking at stale note-derived information simply because their local notes state has not caught up yet and catching up is expensive.

The intended role of the external command is to move that freshness policy out of Git's notes ref synchronization path. A site-specific helper can decide how to obtain current note text for the commit being displayed, such as consulting an external service, doing a targeted lookup, or using its own cache/update policy. Git still owns the coherent git log/show presentation; the helper only supplies the note text to display.

Show 7 quoted lines

> > 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.
> 
> It is unclear why a large body of code that is not documented or
> whose uses are not illustrated by examples found in the test scripts
> is easier to review, though.

Okay my bad. I'll squash them in v2 after this discussion, along with rewording the commit.

Thanks, Siddh