On Wed, Oct 05, 2011 at 11:19:17AM -0700, Junio C Hamano wrote: > Jay Soffian <jaysoffian@xxxxxxxxx> writes: > > > Git has survived w/o needing to lock branches till now. > > Careful. Git has survived without your patch series till now, as people > learned to be careful when they use separate workdirs and avoid certain > things, to the point that they are not necessarily aware that they are > avoiding them (one good practice is to keep the HEADs of non-primary > workdirs detached). > > Does that mean what your patch aims to do is unnecessary? I think not. It seems to me that things like receive.denyCurrentBranch and receive.denyDeleteCurrent are just special hand-rolled versions of the same concept. Could they be implemented using this kind of branch locking? Moreover, I think they would need to be to cope with new-workdir, as the definition of "current" stops being "referenced by HEAD", but becomes much larger. -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