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 -- To unsubscribe from this list: 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
