Subject: Re: [PATCH v3 7/9] refs/files: detect race when generating reflog entry for HEAD

From: Toon Claes <[email-masked]>
Date: Fri, 01 Aug 2025 13:55:31 +0200

Patrick Steinhardt <[email-masked]> writes:

> When updating a reference that is being pointed to HEAD we don't only
> write a reflog message for that particular reference, but also generate
> one for HEAD. This logic is handled by `split_head_update()`, where we:
>
>   1. Verify that the condition actually triggered. This is done by
>      reading HEAD at the start of the transaction so that we can then
>      check whether a given reference update refers to its target.
>
>   2. Queue a new log-only update for HEAD in case it did.
>
> But the logic is unfortunately not free of races, as we do not lock the
> HEAD reference after we have read its target. This can lead to the
> following two scenarios:
>
>   - HEAD gets concurrently updated to point to one of the references we
>     have already processed. This causes us not writing a reflog message
>     even though we should have done so.
>
>   - HEAD gets concurrently updated to point to not point to a reference

That's a little much of pointing, right? ;)

Maybe change it to something like:

    - HEAD gets concurrently updated to no longer point to a reference

-- 
Cheers,
Toon