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

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Thu, Oct 29, 2026, at 19:25, 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.
>
> ;-)

That would be the most elegant. But I think doing a three-way merge
would go too far. Say you have another case where two processes try to
update the note for the same commit C, but the first process edits the
start and the second one edits the end. These are far enough apart that
they merge successfully. But I think that such a race concluding with a
note merge would be wrong in general.