On Fri, Dec 28, 2012 at 07:50:14AM -0700, Martin Fick wrote: > Hmm, actually I believe that with a small modification to the > semantics described here it would be possible to make multi > repo/branch commits work. Simply allow the ref filename to > be locked by a transaction by appending the transaction ID to > the filename. So if transaction 123 wants to lock master > which points currently to abcde, then it will move > master/abcde to master/abcde_123. If transaction 123 is > designed so that any process can commit/complete/abort it > without requiring any locks which can go stale, then this ref > lock will never go stale either (easy as long as it writes > all its proposed updates somewhere upfront and has atomic > semantics for starting, committing and aborting). On commit, > the ref lock gets updated to its new value: master/newsha and > on abort it gets unlocked: master/abcde. Hmm. I thought our goal was to avoid locks? Isn't this just locking by another name? I guess your point is to have no locks in the "normal" case, and have locked transactions as an optional add-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