[RFC] gitweb wishlist and TODO list

[Jakub Narebski <jnareb@gmail.com>]

I am planning on copying features from xmms2's gitweb version 
to git's gitweb, and introducing new ones.

My gitweb can be seen at http://front.fuw.edu.pl/cgi-bin/jnareb/gitweb.cgi
Fetch from http://front.fuw.edu.pl/jnareb/scm/git.git/ (not checked!)


* HTML cleanup - ongoing process of replacing embedded style information
  with CSS styling, adding classes and ids to elements. This is independent 
  on other changes. On top of 'next', as it needs style in separate CSS
  file gitweb.css.

* Storing site-wide gitweb configuration in separate gitweb.conf file.
  Needs GIT_CONFIG patch. Not implemented yet.

  Bootstrapping: gitweb would need location of configuration file.
  Has to be changed in gitweb.cgi itself. Additionally gitexecdir or
  git in PATH is needed to be able to run git-repo-config to read config;
  the solution might be home-grown "parser" to find gitexecdir only.

  Both could be set from Makefile at install stage.

* Add git fetch URL to the project page from gitweb-xmms2. Needs site-wide
  base_url, which need not to be set as there is sane default: use base 
  of gitweb URL.

  Is it useful to allow repository configuration to override it?

* Support for categories from gitweb-xmms2. We can alternatively use
  directory structure of git projects displayed by gitweb as categories.
  Needs I think some site-wide configuration.

  Question: where store categories? .git/category, like .git/description?
  Use gitweb.category key? If yes, do convert description to repository key,
  or perhaps use gitweb.descriptionfile? What should be priority of those
  options if both are set: use repo-config for short (in project listing 
  and in page footer), and from file for long description on project page?
  What if they don't match?

* Refactor dispatch from if...elsif...else construction 
  to using 'name' => \&sub hash.

* Refactor generation of navigation bar. There are at least two
  implementations of that. With hash dispatch it would be easy to
  list all possibilities.

* Add (of course optional, like blame support) snapshot support. There are
  at least two different implementations. I'd prefer to do without second
  CGI script, but perhaps this is better from the performance point of view.
  gitweb-xmms2 has snapshot.cgi in Python: should it be rewritten in Perl?

* Code highlighting for plain view for blobs. gitweb-xmms2 did that using
  GNU highlight program and some embedded configuration (filename regexp to
  syntax used). More generic: run some post-processing. Configurable
  globally (perhaps separate "syntax type" filename or file magic mapping),
  and enabled per repository (default off).

* gitweb-xmms2 has something called committags support: it means that
  'BUG(n)', 'FEATURE(n)' and 'RELEASE: xx' in commit message are turned into
  bugtracker (Mantis for xmms2) or wiki links. It is extension of turning
  sha1-ids into references. Probably needs some extra configuration file,
  and some per repository configuration. Of course we want to support not
  only Mantis, but also e.g. Bugzilla (e.g. Linux kernel) and conventions
  for marking bugs therein.

* gitweb-xmms2 has also etags based anchors to mark function definitions 
  in blob view. I'm not sure it would be that usefull. LXR equivalent,
  perhaps...


Which of those should be implemented first?

Any further ideas for other useful features?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git