Shawn Pearce <spearce@xxxxxxxxxxx> writes: > So a reader-writer lock is preferred over > a non-locking solution such as I posted in > http://article.gmane.org/gmane.comp.version-control.git/30288 ? If you mean these two in your message to be "solution": So the receive-pack process becomes: a. Create temporary pack file in $GIT_DIR/objects/pack_XXXXX. b. Create temporary index file in $GIT_DIR/objects/index_XXXXX. c. Write pack and index. d. Move pack to $GIT_DIR/objects/pack/... e. Move index to $GIT_DIR/objects/pack... f. Update refs. g. Arrange for new pack and index to be considered active. And the repack -a -d process becomes: 1. List all active packs and store in memory. 2. Repack only loose objects and objects contained in active packs. 3. Move new pack and idx into $GIT_DIR/objects/pack/... 4. Arrange for new pack and idx to be considered active. 5. Delete active packs found by step #1. I am not so sure how it solves anything at all. The race is about this sequence: - git-receive-pack is spawned from remove git-send-pack; it lets "index-pack --stdin --fatten" to keep the pack. - index-pack does its magic and moves the pack and idx to their final location; - "repack -a -d" is started by somebody else; it first remembers all the existing packs; it does the usual repacking-into-one. - git-receive-pack that invoked the index-pack waits for index-pack to finish, and then updates the refs; - "repack -a -d" is done repacking; removes the packs that existed when it checked earlier. Now, I am not sure what your plan to "arrange for new pack and idx to be considered active" is. Care to explain? There is a tricky constraints imposed on us by (arguably broken) commit walkers in that it relies on the (arguably broken) sha1_file.c:sha1_pack_name() interface, so naming historical ones $GIT_OBJECT_DIR/pack/hist-X{40}.pack would not work; we would need to fix commit walkers for that first. - 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