Christian Couder <christian.couder@xxxxxxxxx> writes:
> On Mon, Dec 9, 2024 at 12:11 PM Karthik Nayak <karthik.188@xxxxxxxxx> 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.
>
> Maybe something like: "For a given ref in a given transaction there
> can be at most one update."
>
Sure.
>> 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.
>> 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!
Attachment:
signature.asc
Description: PGP signature
