Stefan Beller <sbeller@xxxxxxxxxx> writes: > Unlike transaction_update_ref, this writes out the proposed contents of the > reflog to a temporary file at transaction_reflog_update time instead of > waiting for the transaction waiting to be committed. This avoids an > explosion of memory usage when writing lots of reflog updates within a > single transaction. Copying an existing reflog with thousands of entries over so that I can append a single new entry, just so that I can rollback by not renaming? After ensuring that you are the only process that holds a write fd to the reflog file (e.g. by taking a lock on the ref itself), shouldn't you be able to ftell(), write() and then truncate() to roll back sanely before close()? After all you are not protecting from power loss and other kinds of glitches that would leave *.lock file behind, so... -- 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