Re: [RFC] gitweb wishlist and TODO list

From: Jakub Narebski <jnareb@gmail.com>
Date: Sep 25, 2008, 12:23 UTC
Message-ID: <200809251423.56983.jnareb@gmail.com>
In-Reply-To: <CCF9B7B7-4D85-4704-9363-2CE41B048828@simplicidade.org>

Pedro Melo wrote:

Show 12 quoted lines

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

Show 5 quoted lines

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

Show 16 quoted lines

> > * 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