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

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

Jakub Narebski venit, vidit, dixit 21.02.2011 23:06:

quoted

On Tue, 15 Feb 2011, Michael J Gruber wrote:

quoted

Jakub Narebski venit, vidit, dixit 14.02.2011 20:39:

quoted

quoted

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.

...

quoted

Current requirements are:

[...]

quoted

quoted

quoted

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

quoted

quoted

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.

quoted

quoted

quoted

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