Re: [RFC/PATCH 1/4] gitweb: Move subroutines to Gitweb::Config module

On Sat, 12 Jun 2010, Ævar Arnfjörð Bjarmason wrote:

On Sat, Jun 12, 2010 at 01:01, Jakub Narebski [off-list ref] wrote:

quoted

On Tue, 8 June 2010, Ævar Arnfjörð Bjarmason wrote:

quoted

I haven't contributed to Gitweb, nor do I have to deal with it. But
I've followed this series and reviewed most of the Perl code in
Git. Take these with a grain of salt.

It would be very useful for the future of our Perl code if we had a
dual-life system in Git. I.e. a cpan/ directory where we could drop
CPAN modules that should be shipped with Git.

The standard name for such directory is 'inc/', I think.

Perl itself uses cpan/, but Module::Install started the inc/. What we
call it really doesn't matter though.

Right.

Although better example would be what modules on CPAN use, rather than
what Perl itself uses.

quoted

quoted

Then we could just use e.g. Config::General (~3k lines of code)
instead of writing our own config system. There are probably lots of
wheels that we're inventing (and are going to invent) that have been
done better elsewhere, with more testing.

The problem with _optional_ Config::General config is that people
would have incompatibile gitweb config files, some using Config::General
syntax, some current configuration in Perl.

Isn't the current patch series the first attempt at config file
support? I.e. it's always been editing the source until now.

Errr... no!

$ git blame -C -C -w -L/^our.*'GITWEB_CONFIG'/,+12 gitweb/gitweb.perl
shows that current config file in Perl (loaded using 'do $file') is
with gitweb since at least 2006-08-02.
 

In any case, proper non-executable config file support could easily be
made optional, hopefully with a transition the non-executable one.

I'm not sure if it would be easy to translate currently used gitweb
config files to non-executable file format.  I think that %feature
hash make it so such config format would have to support nested 
structures, which means e.g. JSON or YAML.

Besides how would you store / define $export_auth_hook in non-executable
file format?

  # show repository only if this subroutine returns true
  # when given the path to the project, for example:
  #    sub { return -e "$_[0]/git-daemon-export-ok"; }
  our $export_auth_hook = undef;

-- 
Jakub Narebski
Poland