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

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. But, we can theoretically have multiple reflog
updates in a given transaction.

Nit: Giving an example might help understand where multiple reflog
updates can happen in a given transaction. Alternatively pointing to
an existing doc that contains such an example or explanations might
help too.

Nit:
              lock->count++;

+       } else {
+               ret = lock_raw_ref(refs, update->refname, mustexist,
+                                  affected_refnames,
+                                  &lock, &referent,
+                                  &update->type, err);
+               if (ret) {
+                       char *reason;
+
+                       reason = strbuf_detach(err, NULL);
+                       strbuf_addf(err, "cannot lock ref '%s': %s",
+                                   ref_update_original_update_refname(update), reason);
+                       free(reason);
+                       goto out;
+               }

-               reason = strbuf_detach(err, NULL);
-               strbuf_addf(err, "cannot lock ref '%s': %s",
-                           ref_update_original_update_refname(update), reason);
-               free(reason);
-               goto out;
+               strmap_put(&backend_data->ref_locks, update->refname, lock);
        }

        update->backend_data = lock;