git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[RFC] gitweb wishlist and TODO list

From
Jakub Narebski <jnareb@gmail.com>
Date
Sep 25, 2008, 10:30 UTC
Message-ID
<200809251230.11342.jnareb@gmail.com>

This is yet another series of planned gitweb features. It expands more on new user-visible features than on improving gitweb code (therefore for example using Git.pm/Git::Repo, gitweb caching, and list form of open for pipelines are not mentioned here).

Which tasks / features are most requested? Which tasks should be done first? What do you have on your gitweb TODO list?

All comments appreciated. Thanks in advance.
* 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.
* 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.
* 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.  Of course there would be fallback
  to server-side sorting.
* 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; and/or support for tags, tag clouds,
  removing tags, grouping tags, tags suggestions; and/or support for Trove
  categories (like on Freshmeat, or SourceForge, or Savane/GForge).
* 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)
* Side by side diff (like Wikipedia/MediaWiki), and/or side by side
  comparison (see e.g. Codestriker web review tool).
* Tree blame (when, at what commit and by whom current version of file or
  directory was generated).  This view can be seen in tree/directory view
  of such SCM web interfaces as ViewVC, or GitHub.
* Searching for projects, optionally with paginating projects list page
* Graphical diffstat/dirstat in 'commit' view for merge commits.
* Enhancing gitweb output with RDFa and/or microformats, to make it
  easier to parse unambiguously by machine, for example find fetch
  URL, find push URL, find homepage, parse dates, etc.
* Support for other outline format (XOXO perhaps), and other outlines,
  perhaps also in OPML.
* Etags based anchors to function definitions, i.e. something like
  version-aware source code browser like LXR Cross Referencer (in
  Perl), cscope, Bonsai Project or OpenGrok (unfortunately CDDL
  licensed, and in Java). Should we use Exuberant Ctags
  (http://ctags.sourceforge.net)?
* Optional support for remotes and remote-tracking branches;
  and perhaps support for showing alternates (see forks support)
* Support for patch management interfaces (StGit, Guilt, TopGit), like
  gitk and QGit now have; option to show unapplied patches stack etc.
* AJAX incremental blame, if cached version does not exist
* Better snapshot names, for example <project>-<tag> for tag
  snapshots, perhaps <project>-<branch>-<date> for branch tip
  snapshots, etc.  Ensure that <filename>.<suffix> expands to
  <filename> (see also snapshots of subtrees).
* ...
-- 
Jakub Narebski
Poland
Next: Pedro Melo
Message 1 of 16 in “[RFC] gitweb wishlist and TODO list”
  1. Jakub NarebskiSep 25, 2008
  2. Pedro MeloSep 25, 2008
  3. Jakub NarebskiSep 25, 2008
  4. Pedro MeloSep 25, 2008
  5. Jakub NarebskiSep 25, 2008
  6. Wincent ColaiutaSep 25, 2008
  7. Petr BaudisSep 25, 2008
  8. Jakub NarebskiSep 25, 2008
  9. Petr BaudisSep 25, 2008
  10. Jakub NarebskiSep 25, 2008
  11. Jakub NarebskiSep 30, 2008
  12. Jakub NarebskiSep 25, 2008
  13. Jakub NarebskiSep 28, 2008
  14. Petr BaudisSep 28, 2008
  15. Ask Bjørn HansenOct 1, 2008
  16. Jakub NarebskiOct 1, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.