git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Sitaram Chamarty <sitaramc@gmail.com>
Cc: Jakub Narebski <jnareb@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Tommi Virtanen <tv@eagain.net>
Subject: Re: gitosis-lite
Date: Mon, 24 Aug 2009 08:10:51 -0700	[thread overview]
Message-ID: <20090824151051.GB1033@spearce.org> (raw)
In-Reply-To: <2e24e5b90908240735n5f754c87u960493c92769c0a8@mail.gmail.com>

Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On Mon, Aug 24, 2009 at 6:43 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> > Why not contrib/hooks/update-paranoid (which is written in Perl)?
> 
> Hmmm several reasons.  To start with, it appears to me that
> update-paranoid assumes each user has his own ACL file, and
> I'm going the other way -- you'll notice I have exactly one
> file as a single ACL source for many *projects*, leave alone
> users.

That is true, update-paranoid uses an ACL file per user, because
we approached it from the perspective of "what can this user do"
rather than "what is allowed in this project".

We later ran into needing groups, which meant that in practice the
per-user ACL files really just enumerated what groups they were
a member of, and the group ACL files enumerated what they were
allowed to do in projects.

I can certainly see how this might be backwards, and someone would
prefer the other direction, a per-project listing or something.
 
> Secondly, I want to stick to the gitosis philosophy -- it
> has served very well, and I'm not sure how "in use"
> update-paranoid is.

Well, my prior job used it heavily, and I think is still using it,
a year after I left.  My current job would use it, except that we
went and wrote Gerrit Code Review instead.  :-)
 
> Thirdly, I'm not comfortable having a hook be so complex.
> The whole thing is 10 lines shorter than all my code put
> together :)

Yes, update-paranoid is a big script.  It does a lot.  It not only
checks "can you write in this repository, on this branch" but it
also checks that every commit matches your own email address(es),
and it can also check file path edits, to see if you can modify
the files that were changed.
 
> And finally, it's far too complex for me, leave alone some
> of my users.  I count 6 pipe opens in there,

Not surprised, it needs to read a lot of data from git to do its
job correctly.  It has to enumerate all new commits, any commits
which may be discarded by the update (non-fast-forward), as well
as scan the diff to see which paths were affected.

> and the ACLs
> are read by git cat-file or something

Because I didn't want to check out a copy of the ACLs to the local
disk just to read them into the hook.  The hook pulls them directly
out of a bare "admin" repository, making it easier to push changes
into the repository and have them take effect immediately.

I know Gitosis handles this by having a magic hook in the admin
repository that copies the file out.  update-paranoid just reads
it from git.

> I'll be honest: I
> came away feeling very stupid after trying to read and
> understand that program.  It was... humbling :(

*sigh* That's not good, the hook is meant as a practical example,
if it was too complex to understand, I did a poor job of writing it.
 
-- 
Shawn.

  reply	other threads:[~2009-08-24 15:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-24 12:28 gitosis-lite Sitaram Chamarty
2009-08-24 13:13 ` gitosis-lite Jakub Narebski
2009-08-24 14:35   ` gitosis-lite Sitaram Chamarty
2009-08-24 15:10     ` Shawn O. Pearce [this message]
2009-08-25  3:00       ` gitosis-lite Sitaram Chamarty
2009-08-24 15:43     ` gitosis-lite Jakub Narebski
2009-08-24 18:44 ` gitosis-lite Jakub Narebski
2009-08-25  5:53   ` gitosis-lite Sitaram Chamarty
2009-08-25 12:05     ` gitosis-lite Jakub Narebski
2009-08-26  5:01       ` gitosis-lite 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=20090824151051.GB1033@spearce.org \
    --to=spearce@spearce.org \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=sitaramc@gmail.com \
    --cc=tv@eagain.net \
    /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).