From: Jeff King <peff@peff.net>
To: Nicolas Adenis-Lamarre <nicolas.adenis.lamarre@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Locking files / git
Date: Tue, 17 Sep 2013 17:00:48 -0400 [thread overview]
Message-ID: <20130917210047.GD16860@sigill.intra.peff.net> (raw)
In-Reply-To: <CACPGbcsB-ieZnS5maQgtnRTifFON9fEFpCGGdHtQ2ZjySdxDYA@mail.gmail.com>
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
next prev parent reply other threads:[~2013-09-17 21:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-17 19:45 Locking files / git Nicolas Adenis-Lamarre
2013-09-17 21:00 ` Jeff King [this message]
2013-09-17 21:36 ` Fredrik Gustafsson
2013-09-18 10:12 ` Nicolas Adenis-Lamarre
2013-09-18 21:12 ` Sitaram Chamarty
2013-09-18 19:06 ` Thomas Koch
2013-09-18 21:04 ` Sitaram Chamarty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130917210047.GD16860@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=nicolas.adenis.lamarre@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).