On 02/09/2015 07:50 PM, Stefan Beller wrote: > On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: >> /* >> - * Add a reference update to transaction. new_sha1 is the value that >> - * the reference should have after the update, or null_sha1 if it should >> - * be deleted. If old_sha1 is non-NULL, then it the value >> - * that the reference should have had before the update, or null_sha1 if >> - * it must not have existed beforehand. >> - * Function returns 0 on success and non-zero on failure. A failure to update >> - * means that the transaction as a whole has failed and will need to be >> - * rolled back. >> + * Add a reference update to transaction. new_sha1 is the value that >> + * the reference should have after the update, or null_sha1 if it >> + * should be deleted. If new_sha1 is NULL, then the reference is not >> + * changed at all. old_sha1 is the value that the reference must have >> + * before the update, or null_sha1 if it must not have existed >> + * beforehand. The old value is checked after the lock is taken to >> + * prevent races. If the old value doesn't agree with old_sha1, the >> + * whole transaction fails. If old_sha1 is NULL, then the previous >> + * value is not checked. >> + * >> + * Return 0 on success and non-zero on failure. Any failure in the >> + * transaction means that the transaction as a whole has failed and >> + * will need to be rolled back. > > Do we need to be explicit about having to rollback everything in each > ref_transaction_* function documentation? Thanks for the suggestion. I just added a new commit that moves this (and more) information to the introductory comment above these four functions' declarations, so that it doesn't have to be repeated for each function. It will be in the re-roll. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx -- 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