Re: [RFC] gitweb wishlist and TODO list

[Jakub Narebski <jnareb@gmail.com>]

Pedro Melo wrote:
> On Sep 25, 2008, at 11:30 AM, Jakub Narebski wrote:
> 
> > * Support for FastCGI (via CGI::Fast or FCGI).
> >
> >  Unfortunately I don't use FastCGI.  This has to be done in a very
> >  un-intruisive way, and without performance penalties for "ordinary"
> >  CGI and mod_perl.
> >
> >  Suggested: input reading and validation refactoring.
> 
> Is it ok to require CPAN modules? If yes, then using HTTP::Engine as a  
> base could be helpful here.

No, it is not.  Some gitweb installations (kernel.org, IIRC) are on
tightly managed machines, where installation is severely restricted.
If it is distributed together with Perl package it is best, if it can
be found in distribution packages it is good, if it can be found in
distribution extras it is quite good, if it can be found in trusted
package repository, it is manageable.  Installing untested packages
from CPAN is usually out of the question.

That said...
 
> It supports standalone deployments as well as FastCGI, CGI, mod_perl,  
> POE and others.
> 
> And it acts as a very simple HTTP-layer, without any "framework"
> logic. 

...if we could make it conditional on HTTP::Engine being installed,
and fallback on current code easily, it could be done, I think, without
problems.

Thanks for the pointer. 

> > * Committags support
> >
> >   Support expansion of "tags" in commit messages, like gitweb now
> >   does for (shortened) SHA-1, converting them to 'object' view link.
> >   It should be done in a way to make it easy configurable,
> >   preferebly having to configure only variable part, and not having
> >   to write whole replacement rule.
> >
> >   Possible committags include: _BUG(n)_, bug _#n_, _FEATURE(n),
> >   Message-Id, plain text URL e.g. _http://repo.or.cz_, spam  
> >   protecting of  email addresses, "rich text formatting" like *bold*
> >   and _underline_, syntax highlighting of signoff lines.
> 
> If this part is modular, we can even use a full blown text markup  
> tool, like Markdown or Textile, to generate the HTML version of the  
> commits.

I don't think it is a good idea.  The main target of git commit
messages is command line, so fixed width format is expected.  Commit
mesages are also shown in commit tools and history viewers (git-gui,
gitk, QGit) and in intergration with IDE/editors (KDevelop, Eclipse,
Emacs, Vim).  Unless unprocessed code doesn't loose anything, I think
that advanced markup is a bad, bad idea.

-- 
Jakub Narebski
Poland