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

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).

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to