On 04/01/2014 09:46 PM, Junio C Hamano wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> >> --- > > 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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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