For everyday use we want git to be fast. Creating one commit should not touch the packed refs file. If we do other stuff involving more than one ref, we may accept touching the packed refs file and have a process which takes slightly longer but can handle more complex requests correctly, such as renaming into and from directories (topic/1 -> topic and reverse). Renaming is currently not part of the transaction API because of the (D/F) problems. This proposed change would enable having renames being part of the transactions API. A transaction covers creating, deleting and updating a ref and its reflog. Renaming would be a deletion followed by creating a new ref atomically. So for here is my proposal for small transactions: (just one ref [and/or reflog] touched): In ref_transaction_update: * create $REF.lock file * write new content to the lock file In ref_transaction_commit * commit the .lock file to its destination * in case this is a deletion: * remove the loose ref * and repack the packed refs file if necessary The larger transactions would be handled differently by relying on the packed refs file: In ref_transaction_update: * detect if we transition to a large transaction (by having more than one entry in transaction->updates) if so: * Pack all currently existing refs into the packed refs file, commit the packed refs file and delete all loose refs. This will avoid (d/f) conflicts. * Keep the packed-refs file locked and move the first transaction update into the packed-refs.lock file * Any update(delete, create, update) is put into the locked packed refs file. * Additionally we need to obtain the .lock for the loose refs file to keep guarantees, though we should close the file descriptor as we don't wand to run out of file descriptors. In ref_transaction_commit: * We only need to commit the packed refs file * Discard all other lock files as the changes get committed as a whole by the packed refs file Any feedback would be welcome! Thanks, Stefan -- 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