Jeff King <peff@xxxxxxxx> writes: > But more importantly, it introduces contention between two unrelated > refs that are being updated. Even if we reconcile the differences > automatically (e.g., with a "merge-and-retry" strategy), that is going > to be a serious performance regression for a busy repository, as we > repeatedly try to reconcile the serialized updates to the refs/ root > tree. I think we are on the same page. > Any transactional solution needs to have the equivalent of ref-level > locking (i.e., row-level locking in a relational setting). Not necessarily if we can exploit assumptions such as deletion is far rare compared to update and creation which in turn are far rare compared to lookup. I've been wondering if we can find a cheap reader-writer lock mechanism, use a single instance of it to govern the whole repository, and have everybody but ref deleters and "git pack-ref" take the read side of the lock. Then only while ref deletion or ref packing is going on, everybody need to stall, but otherwise the most common "read or update recently touched refs (aka loose refs)" will be taking the reader side of that cheap read-write lock and reading a single loose ref file. Perhaps such a "cheap on reader side" reader-write lock is hard to come by? -- 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