Re: gitosis-lite

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 24, 2009 at 6:43 PM, Jakub Narebski<jnareb@xxxxxxxxx> wrote:

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

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

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.

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

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 :) I'll be honest: I
came away feeling very stupid after trying to read and
understand that program.  It was... humbling :(

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

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

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

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

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

Thank you very much for your comments!

-- 
Sitaram
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]