On Thu, Oct 23, 2014 at 11:54 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Ronnie Sahlberg <sahlberg@xxxxxxxxxx> writes:
>
>> @@ -3531,7 +3537,7 @@ struct ref_update {
>> enum transaction_update_type update_type;
>> unsigned char new_sha1[20];
>> unsigned char old_sha1[20];
>> - int flags; /* REF_NODEREF? */
>> + int flags; /* REF_NODEREF? or private flags */
>
> Not a very informative comment, I'd have to say. How are users of
> this API expected to avoid stepping on each others' and API
> implementation's toes?
That is an old and bitrotted comment.
I changed it to point to the canonical definition of these flags instead :
int flags; /* The flags to transaction_update_ref[log] are defined
* in refs.h
*/
>
>> @@ -3539,8 +3545,9 @@ struct ref_update {
>>
>> /* used by reflog updates */
>> int reflog_fd;
>> - struct lock_file reflog_lock;
>> + struct lock_file *reflog_lock;
>
> What is this change about?
>
We have one update entry for each line we want to write to the reflog.
So for the first update to a reflog we allocate a lock_file structure.
For any subsequent reflog entry to the same ref we just let the
pointer point to the previous structure we already allocated.
I.e. a way to have only one lock_file structure and share it across
multiple struct ref_update structures.
> Does the lifetime rule for "struct lock_file" described in
> Documentation/technical/api-lockfile.txt, namely, "once you call
> hold_lock_file_* family on it, you cannot free it yourself", have
> any implication on this?
Nope.
>
>> + if (!(update->flags & UPDATE_REFLOG_NOLOCK))
>> + update->reflog_lock = xcalloc(1, sizeof(struct lock_file));
>> +
>
> Hmph, does this mean that the caller needs to keep track of the refs
> it ever touched inside a single transaction, call this without nolock
> on the first invocation on a particular ref and with nolock on the
> subsequent invocation?
Nope. This is not visible to the caller and is managed transparently
inside the transaction code.
>
> Or is the "caller" just implementation detail of the API and higher level
> callers do not have to care?
The latter, the higher level do not have to care.
regards
ronnie sahlberg
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html