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 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html