On Wed, Sep 24, 2008 at 12:15:39AM -0400, Daniel Barkalow wrote: > On Wed, 24 Sep 2008, Dmitry Potapov wrote: > > > > > 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. > > Or you should have to say. But "git lock <filename>" should probably > put the lock on whatever branch "git push" would push to, and similarly > for the other argument combinations that "git push" permits. It seems to me very fragile to rely on the push configuration in deciding what can be locked and what cannot. Besides this configuration can change over time. So what is going to happen with locks then? Another problem: what if I don't push anyway but usually send pull-requests? The fact is if you cannot get your locking working in _one_ repository then any hope that it will work when you have more than one is nothing but a pipe dream. > > > 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. > > Not at all; there are plenty of cases where what matters is the path, and > some things are relevant by virtue of the form of the filename which names > that content. Whether it matters or not depends on a particular workflow and what the developer wants to achieve. Such decisions should be taken by human being, otherwise you are prone to do the wrong things too often. > > > 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. > > In my design, the lock (on the shared repository) is not advisory; if > someone else has it, you can't push if the new commit doesn't match the > old commit for that path. Hey, if someone wants to push this file, it means it is already late, because you _already_ have the situation where two people have edited exactly the same binary file. Isn't the situation that the lock was intended to prevent? So, the goal should be to warn someone who is going to edit file locked by someone else. You cannot prevent him/her from doing so, only to warn about that. As to pushing, it can be different policies. IMHO, the update hook is the best place to express what push you want to allow and what not, but some workflow may not use push at all, yet ability to lock (perhaps, 'synchronize' would be a better word here) may still be needed. 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
