On Mon, 24 August 2009, Sitaram Chamarty wrote: > 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 :) On the other hand having the link in IFAT wiki page could help you gain more users of gitosis-lite (name pending ;-) > > 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, ...") > > 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. > > > 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 ;-) > > > 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. > > > [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 -- 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