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

["Farid Zakaria" <farid.m.zakaria@gmail.com>]

On Thu Oct 29, 2026 at 11:25 AM PDT, Junio C Hamano wrote:
> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>
>> 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.