On Tue, Sep 23, 2008 at 05:13:29PM -0400, Daniel Barkalow wrote: > > The lock needs to last until you push to the repository the lock is for; > otherwise you have the exclusive ability to make changes, but someone who > grabs the lock right after you release it will still be working on the > version without your change, which is what the lock is supposed to > prevent. It still will happen if developers work on topic branches, and it is not a rate situation with Git. Thus locking some particular path is stupid. What you may want instead is too mark SHA-1 of this file as being edited and later maybe as being replaced with another one. In this case, anyone who has the access to the central information storage will get warning about attempt to edit a file that is edited or already replaced with a new version. Dmitry -- 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
