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? I like the new wording (first paragraph) of this function documentation. -- 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