git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Jay Soffian <jaysoffian@gmail.com>
Cc: Brendan Miller <catphive@catphive.net>, git@vger.kernel.org
Subject: Re: preventing destructive operations to central repository
Date: Thu, 15 Apr 2010 18:03:44 -0700	[thread overview]
Message-ID: <20100416010344.GB6181@spearce.org> (raw)
In-Reply-To: <t2q76718491004151758p8862970bua5e7d60ccda8cdae@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> wrote:
> On Thu, Apr 15, 2010 at 8:39 PM, Brendan Miller <catphive@catphive.net> wrote:
> > Let's say you have a bare git repository writeable by a number of
> > different people. How do you prevent them from borking the central
> > repository?
> 
> Depends what you mean by borking, but you might consider starting with
> reading the "git config" man page for the following entries:
> 
> - receive.denyDeletes
> - receive.denyNonFastForwards
> 
> > Also, is there an automated mechanism to ensure that the timeline
> > stays clean? Say, force people to rebase their repositories before
> > merging into the shared repository?
> 
> In order to prevent merges, you will need to use a a receive-pack hook such as:
> 
> http://lists.gnu.org/archive/html/bug-gnulib/2008-10/msg00221.html
> 
> You might also consider something like gitosis/gitolite/gerrit
> depending upon how formal you want to be.

I think his only choice is to install a gitosis/gitolite/gerrit
solution.  Basically he needs to completely remove write access
to the repository, so developers can't muck with it directly.
That requires one of those 3 tools to provide secured proxy access.

On top of those, yea, you would then also want to configure the
receive.denyDeletes and denyNonFastForwards you mentioned above,
as well as maybe also write a custom update or pre-receive hook to
prevent merges from entering the repository.

Though preventing merges is a bit pedantic.  Eventually you'll want
to use a merge rather than a rebase (e.g. merge in a maintenance
branch to pick up its bug fixes into the main development trunk).

-- 
Shawn.

      reply	other threads:[~2010-04-16  1:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-16  0:39 preventing destructive operations to central repository Brendan Miller
2010-04-16  0:58 ` Jay Soffian
2010-04-16  1:03   ` Shawn O. Pearce [this message]

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=20100416010344.GB6181@spearce.org \
    --to=spearce@spearce.org \
    --cc=catphive@catphive.net \
    --cc=git@vger.kernel.org \
    --cc=jaysoffian@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).