On 06/07/2016 07:50 PM, Junio C Hamano wrote:
> Michael Haggerty <mhag...@alum.mit.edu> writes:
>
>> From: David Turner <dtur...@twopensource.com>
>>
>> Instead of including a files-backend-specific struct ref_lock, change
>> the generic ref_update struct to include a void pointer that backends
>> can use for their own arbitrary data.
>
> Hmph.
I don't know what your comment means. This step is a consequence of the
design decision to stick with a single ref_transaction class that is
used by all ref_stores, which was nice because it avoided the need to
virtualize the functions
ref_transaction_{begin,update,create,delete,verify}.
>> @@ -3591,7 +3590,8 @@ static int lock_ref_for_update(struct files_ref_store
>> *refs,
>> for (parent_update = update->parent_update;
>> parent_update;
>> parent_update = parent_update->parent_update) {
>> - oidcpy(&parent_update->lock->old_oid, &lock->old_oid);
>> + struct ref_lock *parent_lock =
>> parent_update->backend_data;
>> + oidcpy(&parent_lock->old_oid, &lock->old_oid);
>> }
>> ...
>> @@ -3745,7 +3745,7 @@ static int files_transaction_commit(struct ref_store
>> *ref_store,
>> /* Perform updates first so live commits remain referenced */
>> for (i = 0; i < transaction->nr; i++) {
>> struct ref_update *update = updates[i];
>> - struct ref_lock *lock = update->lock;
>> + struct ref_lock *lock = update->backend_data;
>
> OK, and files_* backend method downcasts it to what it wants, which
> is good.
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
