Subject: [RFC] gitweb wishlist and TODO list

From: Jakub Narebski <[email-masked]>
Date: Fri, 25 Apr 2008 15:14:35 +0200

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