On Tue, Apr 01, 2014 at 05:58:30PM +0200, Michael Haggerty wrote: > Add a new option flag, LOCK_SEPARATE_STAGING_FILE, that can be passed > to hold_lock_file_for_update() or hold_lock_file_for_append() to use a > staging file that is independent of the lock file. > > Add a new function activate_staging_file() that activates the contents > that have been written to the staging file without releasing the lock. > > This functionality can be used to ensure that changes to two files are > seen by other processes in one order even if correctness requires the > locks to be released in another order. Can you give an example of when this is useful? I'm guessing the application is for writing out packed-refs before pruning loose refs in git-pack-refs? It seems like this makes the API much more confusing. If I understand correctly, this is basically allowing us to take a lock, write to _another_ tmpfile that is not the lock, then rename the tmpfile into place without releasing the lock (and then we can drop the lock at our convenience). I wonder if it would be simpler to build an API for that around the lock_file API, rather than as part of it. Or am I misunderstanding what's going on? -Peff -- 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