www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sitaram Chamarty <sitar...@gmail.com>
Subject Re: Full support for Git at Apache, a dangerously indigo plan.
Date Thu, 04 Nov 2010 01:30:01 GMT
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.

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.

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.

 - 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...

   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.

 - 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 :-)

[1]: https://github.com/sitaramc/gitolite/blob/pu/doc/big-config.mkd#_storing_usergroup_information_outside_gitolite_like_in_LDAP_

[2]: https://github.com/sitaramc/gitolite/blob/pu/doc/admin-defined-commands.mkd#_enable_disable_push_access_temporarily

[3]: https://github.com/sitaramc/gitolite/blob/pu/contrib/adc/who-pushed

-- 
Sitaram

Mime
View raw message