On Tue, Sep 23, 2008 at 06:29:53PM -0400, Daniel Barkalow wrote: > On Wed, 24 Sep 2008, Dmitry Potapov wrote: > > > 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. What are you saying is that when I am locking some file on the current branch, Git (or whatever script that performs this locking) should figure out what is the original shared branch for it and lock the file there. When you have finished to edit and push changes then the lock should be removed if changes are pushed to this shared branch, otherwise it should be some token of delegation to the project maintainer who is going to push (or probably first merge, because other files may need that) to this branch. Maybe, it can work, but it sounds too complex to me. I believe that my idea using SHA-1 is better. After all, what is file? It is its content. At least, in Git, we always identify files by their content. Thus if you lock some file, you put a lock on certain SHA-1. Now, regardless of branches and paths, this lock can work provided that you have access to some shared location. Of course, this lock is purely advisory, but it is good, because you may want to ignore it in some case. For instance, you want to created a new branch based on the current shared location and have no plan to ever merge it back. In this case, the lock on the shared branch should not matter to you. This is true regardless how you implement locking, and in your scheme it will another special case. 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
