Christian Couder [off-list ref] writes:

On Mon, Dec 9, 2024 at 12:11 PM Karthik Nayak [off-list ref] wrote:

quoted

When refs are updated in the files-backend, a lock is obtained for the
corresponding file path. This is the case even for reflogs, i.e. a lock
is obtained on the reference path instead of the reflog path. This
works, since generally, reflogs are updated alongside the ref.

The upcoming patches will add support for reflog updates in ref
transaction. This means, in a particular transaction we want to have ref
updates and reflog updates. For refs, in a given transaction there can
only be one update.

Maybe something like: "For a given ref in a given transaction there
can be at most one update."

Sure.

quoted

But, we can theoretically have multiple reflog
updates in a given transaction.

And: "But we can theoretically have multiple reflog updates for a
given ref in a given transaction."

Will add.

quoted

diff --git a/refs/files-backend.c b/refs/files-backend.c
index 13f8539e6caa923cd4834775fcb0cd7f90d82014..9c929c1ac33bc62a75620e684a809d46b574f1c6 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c

@@ -71,6 +71,8 @@ struct ref_lock {
        char *ref_name;
        struct lock_file lk;
        struct object_id old_oid;
+       /* count keeps track of users of the lock */
+       unsigned int count;

Nit: maybe the following is a bit better:

      unsigned int count; /* track users of the lock (ref update +
reflog updates) */

This is better, will amend this in too!