Re: [PATCH] notes: do not drop notes written by a concurrent process

On Thu Oct 29, 2026 at 11:25 AM PDT, Junio C Hamano wrote:

"Kristoffer Haugsbakk" [off-list ref] writes:

quoted

Instead, maybe this would happen in an ideal world:

1. `master` and `feature1` race to commit a note
2. `master` wins
3. `feature1` notices that there is a new note commit (from `master`)
4. It checks whether that commit changed the commit that *it*
   (`feature1`) wanted to update
   • If so: fail
   • If not: continue
5. `feature1` retries (go to (1))

Maybe this is too much logic for a “porcelain” command (interactive
use), but there is no plumbing Notes command.

Or possibly

 1. two races. Both remembers what commit was at the tip of the
    notes tree (call it commit #1).

 2. each creates a new note commit on top of #1.  Call them commit
    #2master and #2feature1.

 3. 'master' one wins the race.  As #2master is a fast-forward from
    #1, the notes tree gets #2master at its tip.

 4. 'feature1' loses the race.  It merges #2feature1 into, or
    rebases #2feature1 on top of, #2master and updates the notes
    tree.

;-)

Your proposals for retries when possible make sense but I may leave that
to you to implement.

I felt confident reviewing the current patch at it's current state
(AI-assisted) and I do concur that it's a net-positive change in the
interim.

(I guess I could try to implement the retry logic - AI
assisted if you like)

Would it be OK if I also suggested the other two bugs (+small fixes)
I found on the mailing list (with the same tool)?

They are:
* Similar race-type bug for credential-cache leaving a stale daemon+credential
* fsmonitor daemon keeps running after its worktree is deleted or moved

Both patches are of similar size and complexity to this one, with a test
case.