This is yet another series of planned gitweb features. It expands more on tasks improving gitweb; new features are mentioned only in general view. Which tasks / features are most requested? Which tasks should be done first? All comments appreciated. 1. Cleanup * HTML: use classes for styling elements. There are still some places where we use presentational HTML elements like <i>. I'd rather have it replaced by adding class to appropriate element, and adding proper rule to CSS. This would make changing the style easier, but it would make generated a bit longer page larger. Other issue with above is with web browsers which do not implement CSS, so it would be good to retain presentational elements, perhaps adding styling to those elements. On the other hand we use class element when sometimes id attribute would be better, and sometimes (in the tables) it would be better served to add <col> and <colgroup> elements, and use header attribute and select CSS style by this attribute value. * CSS: remove repetitions, use more elaborate selectors. Use descendant selectors more, and use other selectors like parent or grandchild, instead of relying on class iself. The goal is to remove some of repetition in CSS file. For example we could state that all "second level" divs, perhaps with some exceptions, should have 8px padding. This would make adding similar elements easier (for example README for a project had for a while no padding), and most probably would make CSS style smaller, but at the cost of CSS being more complicated (more complicated selectors, knowledge of cascading (priority) sequence). Perhaps we should reorder CSS file, and add some comments, to make it's maintenance easier, and make it easier to add style for new elements. * Code: make code more readable. Some time passed by since renaming subroutines to better reflect what they do, and moving them to group similar subroutines together. But since then gitweb gathered more subroutines, other subroutines were modified. It would be nice if somebody with fresh view examined the code and, if it is needed, proposed subroutines renaming, changes in subroutines calling conventions, and move code around to have similar subroutines together. * Code refactoring: separate code dealing with similar things. Gathering together code dealing with various log-like views, i.e. code dealing with 'log', 'shortlog', 'history' and 'rss'/'atom' actions (and perhaps also 'search' action for searching commit messages) would allow for improvements to "log" code to apply to all those views. It would make also easier to add another log-like views, for example 'raw' or 'plain' or 'mbox' view, or more delatiled search results (e.g. with context) for searching commit message. Another bit of code that could be put into separate subroutine is code dealing with "item" views, i.e. links for each tag in a list of tags, links for each entry in a 'tree' view, links for each commit in a 'shortlog' or 'log' view, etc. Yet another, code displaying single structured object, like 'tag' and 'commit' view. This would also make it easier to change the style used by gitweb everywhere simultaneously, without worrying that we forgot some place. * Code: list form of open pipeline (?) Gitweb uses list form of open to run git commands, avoiding (negligible) cost of forking shell, and (non negligigle) trouble with shell-quoting command arguments. But when output must be passed to other command, gitweb falls back to "shell" form of open. Currently this happens only for snapshot formats using external compresor, now that pickaxe search got rewritten to use git-log, instead of git-rev-list fed to git-diff-tree. But if gitweb is to get syntax highlighting using some external tool, it would be better to have some kind of "list form of open" to open pipelines. * Code: deal with utf8 when reading data (?) Currently gitweb converts from utf8 to Perl internal form using (misnamed) to_utf8() subroutine when writing out (printing out) via esc_html(), or by calling to_utf8() explicitely. It would be less error-prone to force conversion to Perl internal form when reading data from external sources, and always store data in variables in Perl internal form. * Code: input reading and validation refactoring. Currently gitweb reads values of CGI parameters into global variables, performing in the meantime basic validation of parameters. It is done independently if current action access all the [possible] parameters. Perhaps this should be separated into subroutine. This should help to have better FastCGI and probably also "native" mod_perl support. It would also show which actions use (and require) which parameters. 2. Performance etc. * Better 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. * Optional information about load stats Add an option to display information about how much time it took to generate page, how many git commands were called, and possibly other metric; if page was cached, write when it was generated, and how much time till timeout. This probably would require additional perl modules, and it should be conditional on those modules. * Gitweb caching Add caching to gitweb, either caching of output, or caching of intermediate Perl structures. Support proper replies to HTTP cache (in)validation requests. This is one of GSoC 2008 projects. Bundled together is using "infinite" (or at least large: currently we use +1d) Expires: and/or Cache-Control: max-age (if HTTP/1.1) for unchanging pages. Although those pages are usually rarely accessed... * Reduce size of project list page Now that gitweb is used for installations spanning thousands of repositories, showing all projects (repositories) in the front page is hard on server (this can be migitated by caching), but also hard on browser which has to render huge table / huge page. One solution would be to divide projects list page into pages; this would have the advantage that for sorting by project name (default), or by project owner gitweb would have to get data (owner, last change) only for the projects shown. Alternate solution, if categories support would got implemented, would be to show only list of categories. Yet another would be to put projects search form as homepage (front page). * AJAX sorting of tables Implement sorting tables (projects list, fork list, heads, tags) in browser using JavaScript, like tables in Wikipedia (if possible). This would reduce server load, too. 3. New features * 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. * Project categories support * Syntax highlighting for "blob" view (in general: blob output filter) * New log views (formats) New log-like views could include: 'log' view with path limiter, 'whatchanged' like view with list of changed files, 'mbox' format (aka 'plain' format) to be used by git-am, etc. This would I think require changes to log showing infrastructure. * Enable showing blob size in 'tree' view (optional) * Graphical log (like gitk, qgit, tig, or git-browser) perhaps also graphical view of forks like in GitHub * Enable transparent compression for HTTP output (for performance reasons it makes sense to do it only for cached output) -- 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
