On Fri, Apr 1, 2011 at 17:39, Junio C Hamano <gitster@xxxxxxxxx> wrote: > While I am not sure if letting a clone proceed while there is a concurrent > push is even a good idea to begin with, What? Why? Are you suggesting that Git hosting sites disable readers while there is a push occurring? We have tried hard to design Git to be concurrent reader/writer safe, *except* the actual garbage collection part of `git gc` that deletes loose objects. There is no reason to prevent concurrent readers while there is a push in progress. The only problem is a cpio based clone, which may link the objects directory before the refs, and miss linking the new pack but wind up linking the new ref, making the clone corrupt. But that is a bug in the cpio clone implementation. Using file:// to use the classical pipe is safe here, because the refs are scanned before the objects are. IMHO, if you think clone during push is unsafe because of this, we should fix the cpio clone path to do a `git ls-remote` on the source, cache the refs in memory, copy the objects, then write out a packed-refs file containing the refs we snapshotted *before* linking the objects directory into the new clone. -- Shawn. -- 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