Re: [PATCH v2 20/27] update-ref --stdin: Reimplement using reference transactions

[Michael Haggerty <mhagger@alum.mit.edu>]

On 04/01/2014 09:46 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> This change is mostly clerical: the parse_cmd_*() functions need to
>> use local variables rather than a struct ref_update to collect the
>> arguments needed for each update, and then call ref_transaction_*() to
>> queue the change rather than building up the list of changes at the
>> caller side.
>>
>> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
>> ---
> 
> With the implementation of ref_transaction at this point in the
> series it does not matter, but the updated code in this patch means
> that it is perfectly acceptable to do this sequence:
> 
>     ref_transaction_begin();
>     ref_transaction_update();
>     ...
>     ref_transaction_update();
>     die();
> 
> without ever calling ref_transaction_rollback() API function.
> Depending on the future backends, we may want to ensure rollback is
> called, no?  And if that is the case, we would want to prepare
> callers of the API with some at-exit facility to call rollback, no?

I assumed that rolling back a non-consummated transaction in the case of
early program death should be the responsibility of the library, not of
the caller.  If I'm correct, the caller(s) won't have to be modified
when the atexit facility is added, so I don't see a reason to add it
before it is needed by a concrete backend.

But you suggest that the caller should be involved.  Do you have an idea
for something that a caller might want to do besides roll back the
transaction?

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/