The future of git-instaweb (was: Re: The future of gitweb (long term goals))

From: Jakub Narebski <jnareb@gmail.com>
Date: Feb 25, 2011, 22:37 UTC
Message-ID: <201102252337.28364.jnareb@gmail.com>
In-Reply-To: <4D64E75A.3050506@drmicha.warpmail.net>

On Wed, 23 Feb 2011, Michael J Gruber wrote:

Show 9 quoted lines

> Jakub Narebski venit, vidit, dixit 21.02.2011 23:06:
>> 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:

[...]

Show 16 quoted lines

>>>> - 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.
> 
> Cool, I didn't know, but it's a great feature.
> By "easy installation" I mean being able to use it without having to
> configure a "central" web server, i.e. just the way a git+gitweb in
> $HOME can run instaweb without admin rights.

Yes, the idea of git-instaweb is to be able to run browser with gitweb showing current repository, which means running some kind of web server. Selected web server is run in "user mode", with config file generated by git-instaweb, and with port number > 1024 (so non-root can open it). Web server can be installed system-wide by administrator (for example apache or lighttpd), or installed locally (for example plackup with local::lib).

Show 8 quoted lines

>>> 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?
> 
> E.g., using an installed gitweb - I just learned it does that already!

This (git-isnatweb using installed gitweb) has its advantages and disadvantages.

Pro: ~~~~ The main reason behind changing git-instaweb so it uses installed gitweb (after 'install-gitweb' target was added to git Makefile, of course) in c0cb4ed (git-instaweb: Configure it to work with new gitweb structure, 2010-05-28) was to be able to use git-instaweb with split gitweb. This commit by Pavan Kumar Sunkara was part of ultimately failed Google Summer of Code 2010 project that was meant to add ability to edit repositories to gitweb, of which first part was splitting gitweb into modules (packages) for better maintability.

Second reason was to avoid duplication of disk space: generated git-instaweb script included the whole gitweb.cgi script, and some of its static files like e.g. gitweb.css.

Contra: ~~~~~~~ This change means that git-instaweb requires gitweb to be installed to work. (Of course gitweb can be installed locally, and you can configure git-instaweb to use specified version of gitweb / specified gitweb script.)

There is also issue of packaging and dependencies: e.g. should git-instaweb be a part of gitweb RPM package?

> Also, the graph viewer, i.e. including it as a module with the same
> "looks" as the rest of gitweb.

Errr, I think this is to be gitweb feature, rather than git-instaweb feature. Don't you agree?

> I don't know how customisable gitweb's layout is right now (CSS). That
> might be important for some.

You can change CSS, you can add additional CSS files (e.g. change default font size) quite easily.

> [...]                        Personally, whenever I'm on the more 
> "modern" repo hosters, I'm longing for the clean interface and high
> information density of gitweb.

OTOH high information density (and lots of hyperlinks) make for steeper learning curves, while adding power.

Show 14 quoted lines

>>>> 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.
> 
> 100% agreed. Also, smaller modules make it easier for new gitweb
> contributors to join and help.

Right.

-- 
Jakub Narebski
Poland