From: Siddh Raman Pant <siddh.raman.pant@oracle•com>
To: "gitster@pobox•com" <gitster@pobox•com>
Cc: "git@vger•kernel.org" <git@vger•kernel.org>,
"calvinwan@google•com" <calvinwan@google•com>,
"newren@gmail•com" <newren@gmail•com>, "ps@pks•im" <ps@pks•im>,
"code@khaugsbakk•name" <code@khaugsbakk•name>
Subject: Re: [PATCH 7/9] notes: support an external command to display notes
Date: Wed, 20 May 2026 06:59:36 +0000 [thread overview]
Message-ID: <aaf25b8c84a51d0a3156af1944ec39b51f764019.camel@oracle.com> (raw)
In-Reply-To: <87fr3nq74l.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]
On Wed, May 20 2026 at 05:33:54 +0530, Junio C Hamano wrote:
> 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.
> > 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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-05-20 6:59 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 16:30 [PATCH 0/9] Add support for an external command for fetching notes Siddh Raman Pant
2026-05-19 16:30 ` [PATCH 1/9] Documentation/git-range-diff: add missing notes options in synopsis Siddh Raman Pant
2026-05-19 23:47 ` Junio C Hamano
2026-05-20 7:00 ` Siddh Raman Pant
2026-05-21 0:28 ` Junio C Hamano
2026-05-21 4:13 ` Siddh Raman Pant
2026-05-19 16:30 ` [PATCH 2/9] notes: convert raw arg in format_display_notes() to bool Siddh Raman Pant
2026-05-19 16:30 ` [PATCH 3/9] wrapper: add sleep_nanosec Siddh Raman Pant
2026-05-19 23:50 ` Junio C Hamano
2026-05-20 7:07 ` Siddh Raman Pant
2026-05-19 16:30 ` [PATCH 4/9] run-command: add support for timeout in command finisher Siddh Raman Pant
2026-05-21 7:21 ` Johannes Sixt
2026-05-21 8:39 ` Oswald Buddenhagen
2026-05-21 9:59 ` Siddh Raman Pant
2026-05-21 14:36 ` Johannes Sixt
2026-05-22 0:10 ` Junio C Hamano
2026-05-22 5:46 ` Siddh Raman Pant
2026-05-22 5:10 ` Jeff King
2026-05-22 5:59 ` Siddh Raman Pant
2026-05-19 16:30 ` [PATCH 5/9] wrapper: add support for timeout and deadline in read helpers Siddh Raman Pant
2026-05-19 16:30 ` [PATCH 6/9] t3301: cover generic displayed notes behavior Siddh Raman Pant
2026-05-19 16:30 ` [PATCH 7/9] notes: support an external command to display notes Siddh Raman Pant
2026-05-20 0:03 ` Junio C Hamano
2026-05-20 6:59 ` Siddh Raman Pant [this message]
2026-05-21 1:12 ` brian m. carlson
2026-05-21 4:12 ` Siddh Raman Pant
2026-05-21 21:18 ` brian m. carlson
2026-05-19 16:30 ` [PATCH 8/9] Documentation: document external notes command options Siddh Raman Pant
2026-05-19 16:30 ` [PATCH 9/9] t: add tests for external notes command Siddh Raman Pant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aaf25b8c84a51d0a3156af1944ec39b51f764019.camel@oracle.com \
--to=siddh.raman.pant@oracle$(echo .)com \
--cc=calvinwan@google$(echo .)com \
--cc=code@khaugsbakk$(echo .)name \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=newren@gmail$(echo .)com \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox