Re: gitosis-lite

On Mon, 24 August 2009, Sitaram Chamarty wrote:

On Mon, Aug 24, 2009 at 6:43 PM, Jakub Narebski[off-list ref] wrote:

quoted

Could you add information about this tool (perhaps after confirmation
/ deciding on project name[1]) to Git Wiki page
 http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
somewhere below Gitosis?  Please do not forget to include that it is
written in Perl; see other entries for example.

Will do; though I'll probably wait until at least one person
other than me has used it :)

On the other hand having the link in IFAT wiki page could help you
gain more users of gitosis-lite (name pending ;-)

quoted

You wrote in project's README.markdown that you were inspired by
Gitosis (which requires Python and python-setuptools) and
Documentation/howto/update-hook-example.txt (which uses bash).
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.

Well, gitosis uses single SSH user: 'git' (by default, at least).

Also from what I understand update-paranoid uses the same set of ACLs
for all projects (well, depending how $acl_git and $acl_branch are
defined).
 

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.

I wonder about this too.
 

Thirdly, I'm not comfortable having a hook be so complex.
The whole thing is 10 lines shorter than all my code put
together :)

The update-paranoid hook has inline POD documentation, which adds to
its size (I think that your gitosis-lite (name pending) should also
use this Perl literate programming convention).  On the other hand
this documentation is not, unfortunately, up to date; for example
it allows to control which directories you can change, which is not
documented in POD.

And finally, it's far too complex for me, leave alone some
of my users.  I count 6 pipe opens in there, and the ACLs
are read by git cat-file or something :)

That's because update-paranoid, like gitosis, uses configuration in
$scl_repo repository.  git-cat-file is low level (plumbing) equivalent
of git-show (porcelain).

Those pipelines are required for strict (paranoid) access control that
update-paranoid uses: checking that committers are on allowed list,
that taggers are on allowed list, that branches points to commits, that
tags points to tag objects, etc.

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

On the other hand it uses subroutine prototypes (unnecessary, and not
recommended), old-style bareword filehandles instead of lexically scoped
filehandles ("open I, ..." vs "open my $fh, ...")
 

quoted

Using Perl code for configuration is simple and fast, but not very
secure.  Why not use git config format (via "git config -l -z" like in

Not secure in what sense?  Only the "git admin" (whoever
owns the account in which gitosis-lite is running) will be
able to generate it, and only scripts that run with his
authority (by way of hooks in repos he owns) can run it.

It cannot do what he did not intend to do, and what he wants
to do he can do anyway, whether it's JSON or perl.

Except for umasking the file, I don't see anything I missed.
Could you help me understand?

Ah, thats O.K. then.

quoted

gitweb), or YAML or JSON (or Storable)?  Well, YAML might be overkill.

One of the objectives is to work *as is* on any Unix system
that managed to install git (which implies Perl).  So, no
JSON or YAML.  Storable would be fine (I think it's also
part of core perl) so if I find a compelling reason I don't
mind switching to that.

One reason to not use Storable is that it is binary.  Another that format
is not exactly stable (but it contains version info, so it is backwards
compatibile I think).

As for dependencies: some people on #perl told me to not worry about
dependencies because there is PAR :-)

All I really have is a nested hash to be saved and restored
-- nothing more complex, no objects, no blessed refs, etc.

JSON would be good then ;-)

quoted

BTW. if you blog about gitosis-lite (http://sitaramc.blogspot.com/)
it could be picked up by Perl Iron Man Blogging challenge, and you
could get wider review.

Will do; thanks.  I did not know my blog got picked up by
anything; till date it has never come up on a google search
or a blog search anywhere, and it's more of a rant-box +
annotated bookmarking service for myself :)

I don't know if it would be picked; still, you can try to submit it to
(join) http://ironman.enlightenedperl.org; note that only posts which
contain one of magic words ('perl', 'ironman', ...) would get picked by
this planet.

quoted

[1]: gitosis-lite doesn't look like CPAN-y name.  Git::Admin perlhaps?

Too presumptuous for someone like me -- makes it sound like
the "one true way to Admin git" :)

Git::Auth perhaps (authentication and authorization)?  
Git::AccessControl?

You can always ask on #perl (also on freenode).
-- 
Jakub Narebski
Poland