Re: git dangerous operations on alioth
On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
>
>
> There was recently some discussion in pkg-javascript about how to give
> more people access to the VCS (e.g. keeping the git repositories
> logically organised under the pkg-javascript tree, but making write
> access available to all DDs + alioth guest users and not just those in
> the pkg-javascript UNIX group)
>
> I generally agree with the principle of giving more people access, but
> git access is `all or nothing'. This is not just true for alioth, it is
> much the same with github hosting and many others.
>
> Has anybody had experience controlling access to git repositories, for
> example, to give users access but prevent some of the following
> dangerous operations?
>
> - prevent users pushing with the `--force' option
> (from the man page for git-push: "This can cause the remote repository
> to lose commits; use it with care.")
--force is a "unshoot your foot" option. It's meant for situations where
you have a set of commits pushed to a repository where you go "oops,
those shouldn't have been published, let's fix that".
If you force a commit, they're not actually lost (you can find them with
git fsck), but they'll no longer be part of your git history.
It can be switched off by enabling the receive.denyNonFastForwards
option on the server; but usually you don't want it disabled, unless you
have a repository that's read by a *lot* of people whom you may not be
able to reach.
> - ensure that users only push commits authored by themselves (email
> address white list)
Why oh why would you want to do that? Git is a distributed version
control system; that means pushing commits which originate from someone
else than yourself should be the rule, not the exception.
> - prevent some users pushing tags (or only allow tags matching a pattern)
You'll need to use a hook script for that, I suppose.
> Github partially works around this issue by providing a convenient web
> UI for managing pull requests: so you simply don't give people access to
> do any commits at all, and you manually review each of their changes,
> although it only requires a couple of mouse clicks to accept each patch.
All github does is provide a web UI around what really already exists in
git itself. I personally don't actually like github's patch merge
infrastructure, to be honest.
It sounds to me like you're approaching git like it's a centralized
version control system. It isn't.
--
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.
Reply to: