Re: The future of gitweb (long term goals)

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 15 Feb 2011, Michael J Gruber wrote:
> Jakub Narebski venit, vidit, dixit 14.02.2011 20:39:

> > Now that we are talking about future of git, including breaking some
> > of backwards compatibility bugs / misdesigns for 1.8.0, perhaps it is
> > the time to discuss long term goals and the future of gitweb.
> ...
> > Current requirements are:
> > - Perl 5.8.x (for proper Unicode / UTF-8 support)
> > - core Perl modules: CGI, Encode, Fcntl, File::Find, File::Basename,...
> > - non-core Perl modules optional, needed for some of extra features
> > - backward compatibility (query params and path_info URLs)
> 
> I'd second that this is important for adaption by some main users.

You mean here backward compatibility of API (i.e. old links keep working),
isn't it?

> > - easy installation even without admin rights
> > - scanning for repositories (as an option)
> > - lightweight
> 
> All of these are important for instaweb also. 

Nowadays git-instaweb uses _installed_ gitweb, so neither easy 
installation, nor installing / running without admin rights is necessary
for use of gitweb in git-instaweb.  Strictly speaking neither is scanning
for repositories; I think git-isnatweb could generate file with list of
repositories (with repository) to show.

> I consider instaweb a very
> underrated feature! (It also needs some works of love, not just
> appreciation, of course.)

Beside adding support for new web servers (like recently added 'plackup'),
what do you thing needs to be done?

> > 1. Splitting gitweb into modules (packages), for better maintainability.
> 
> Also, this may help including other optional parts. The graph viewer as
> used on repo.or.cz sets gitweb apart from quite a few alternatives and
> would be used more widely if it were an optional module shipping with
> gitweb. Just imagine instaweb with graphs ;)
> Also, being part of gitweb, the viewer may attract a few coders.

Well, adding anything major (like e.g. write functionality, output caching;
perhaps graph of history is also in this category) really require split
gitweb.  It is getting hard to maintain gitweb as it is now.

-- 
Jakub Narebski
Poland