www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <p...@querna.org>
Subject Re: Full support for Git at Apache, a dangerously indigo plan.
Date Thu, 04 Nov 2010 03:25:38 GMT
On Wed, Nov 3, 2010 at 9:30 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> Hello,
> Someone pointed me to this discussion, and I thought I'd
> jump in and comment on a few items in that list that struck
> me.
> Before that, I'd also like to say that even if you do not
> use gitolite, if you have questions about gitolite, what can
> it do, how does it do it, why not some other way, pros and
> cons, etc., please feel free to email me; I'd be happy to
> help.  I've joined this list so I'll see those two; although
> I would appreciate it if the subject line had the word
> gitolite somewhere in case this is high traffic.
> That said, here're some random thoughts on the starter email
> in this thread.  Sorry this may not "thread" properly since
> I joined after that email was sent.

Thanks for dropping in;  More feedback like this is very welcome --
none of us at Apache have hosted this many git repositories before, so
any experience and advice is good -- likely by the time we are done we
will have 200-300 separate git repositories.

> Stage 0:
>  - HTTPS based pushing should work quite well with
>   gitolite.  It uses the new "smart http" mode (git 1.6.6
>   or later) of course; it doesn't support the old webDAV
>   method of http access.

Yup, this is the intention :)

> Stage 1:
>  - git slave: gitolite has mirroring capability, but
>   frankly, it all boils down to one line (git push
>   --mirror <someURL>) in a post-receive hook.  That's all
>   you need in git (and possibly other DVCSs are similar).
>   Gitolite just does it a bit more "formally" :-)
>   I see that this is mentioned later in your email also,
>   and yes it does work.  The only things that don't get
>   pushed when you do this are things like hooks,
>   info/exclude, config, etc., which are always considered
>   to be site-local configs and never sent across on push
>   (partly due to security concerns too, of course).
>   You'd have to rsync them separately if needed.

Yes, most likely all of the hooks and basics of a Git repository would
be ironically checked into a Subversion repository -- this is how we
keep track of all our custom hooks in SVN.  We would then use our
existing svn-syncing tools to keep the filesystem copies of them up to

>  - Authorisation is better done in "update" hook than
>   "pre-receive".  Update gets called once for each ref
>   being pushed, so you can accept some and reject others.
>   Pre-receive is all or nothing -- one bad ref can reject
>   all the refs being pushed, which could be confusing.  Or
>   not...

For us Group Authorization is actually mostly going to be on a
whole-repository basis.  I don't think we intend to block individual
commits based on the contents of the commits -- other than possibly
issues with merge commits that haven't really been discussed in depth

>   You can certainly trick gitolite into working like this
>   if needed, but it is not the default.
>  - gitolite *can* use LDAP groups for authorisation.
>   However, it does not know LDAP natively.  See [1] for
>   details on how it does it right now.

We discussed this tentatively at ApacheCon today, and most likely we
will just have a script that generates a group file like we do for

(Hmm, I bet this URL is accessible only to ASF commiters, i'll try to
get that fixed)

>  - temp'ly disabling a repo: you can do this per repo as
>   well; it doesn't have to be sitewide; see [2] for
>   details.  Might be useful on occasion...
>  - do not allow push -f: this is a fundamental feature of
>   gitolite :-)  However, if you want a blanket "no one
>   should ever push -f" you can do it quite easily even
>   without gitolite.  Gitolite is useful when you want to
>   allow this for some people and not to others.
>  - logging: gitolite logs the apache "pusher", along with
>   the SHAs involved.  The SHAs in turn give you the git
>   "committer".  One use for this is [3].
>  - [warning: opinion here] email notification: seems to
>   indicate a preference for "small number of large
>   commits" (reading between the lines).  Git is best when
>   you have a large number of small commits, for all sorts
>   of reasons :-)

No, I would say most projects prefer a large number of small commits
-- we just have many many historical processes and people's
preferences accustomed to email based workflows.  Moving to git should
not change these email workflows.



View raw message