On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote: > Ooops. It seems that each time somebody says these two words together, > people hate him, and he is scorned by friends and family. And strangers on mailing lists. :) > However, > - gitolite implement it (but gitolite is not git). Yes, and I think that distinction is important. Locking is fundamentally about having a centralized server. Even if you have some decentralization (e.g., let's imagine two divisions of a company that work as peers), the whole point of the lock is that multiple people are communicating with the same lock server (so in that same example, from the perspective of people in those divisions, there is a central server for each division, and that would be the lock server). Git itself does not know know or care about your workflow, and whether the remote you are pushing to is central or not. Having a lock server would be unlike the rest of git. Whereas gitolite, since it is about managing access to a centralized repository, is a good place to handle locking. In other words, I do not think locking is inherently bad. It is only that it is useful for a subset of workflows that git provides. So I don't think that git is the right place to implement it; rather it should be built on top, either standalone or as part of other tools that already assume some centralization. > I want to explain how I could implement it. > [...] That all sounds like a reasonable workflow, but I think you could just as easily implement it on top of git. In particular, the protocol does not have any room to communicate this data. So you are already going out-of-band over ssh, or something similar. The only support you need from git is to auto-unlock the files after a push. And I think you could do that using a post-receive hook. And indeed, you would not want git itself to do it anyway, because the rules for when to unlock are going to depend on your workflow (e.g., which branches a commit must hit to trigger an unlock). -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