On Wed, 24 Sep 2008, Dmitry Potapov wrote: > 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. No, your goal is to avoid having to do a merge in order to do a particular push. That push is the push to the shared location. It doesn't matter if you use topic branches, because your eventual goal is still to push to the shared location (or, possibly, to have the project maintainer push to the shared location with some sort of interesting delegation), so you lock the shared location, not your topic branch. On the other hand, it's easily possible that other people (or you) want to fork the image, such that only some locations (either different paths in the project or the same path in different branches) get your change and other branches get different changes made at the same time. Of course, if you want to change multiple things, you need to get multiple locks. -Daniel *This .sig left intentionally blank* -- 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
