This is second series of planned gitweb features. Still ideas for many of them come from xmms2's gitweb version, which can you see in work at http://git.xmms.se/?p=gitweb-xmms2.git;a=summary Some of gitweb features like snapshot support and clone/fetch URL were implemented, some of cleanup like refactoring navbar generation or putting CSS into separate style file too. I have put the list here for three reasons. First to get input which features are most wanted, and to receive perhaps ideas for new features. Second, to have TODO list, and receive input if somebody is doing implementing some of the features to avoid duplicate work. Third, and most important, some of features needs discussion about _how_ to implement them. Copy sent to Sham Chukoury, owner of gitweb-xmms2. Cleanup, tidying, refactoring: * HTML code still needs cleanup. All elements should have be either assigned class, or given unique id. Presentational elements like <i> or <b> should be replaced by styling using CSS. Page should be divided into block elements; avoid overuse of <br/>. * CSS cleanup. Names of classes should reflect intent, not be replacement for presentational elements, or be incomprehensive: e.g. classes age0, age1, age2, dark, light. padding: 8px; repeats many times, perhaps it could be replaced by setting margin in encompassing element, or via inheritance or additional class. * Separate generating link and related links to object (e.g. "blob | blame | history | raw" for blob in "tree" view) into subroutine, similarly to refactoring navbar. The problem is that the set of links depends not only on the type of object, but also on the action/view we are in, for example links to commit object might be either "commit | commitdiff", or "log | shortlog" if the commit is considered ref. DISCUSSION needed. * Collapse similar subroutines into one, e.g. git_blob and git_blob_plain, and use parameter to set format. Perhaps instead of having sub git_commitdiff_plain { git_commitdiff('plain'); } we can simply use my %actions = ( # ... "commitdiff_plain" => sub { git_commitdiff('plain'); } # ... ); Which of this options is more readable, which one is faster? * Refactoring formatsnav similarly to commit/hashbase related main navbar (upper part of navbar now). For blob it would be "html", "plain", "blame", "head" (or "base"), optionally "HEAD", "history", perhaps later "highlight". For tree it would be "tree", "blame" and "history". For commit it would be "html", "plain", and "combined" if applicable. * Perhaps some of the views should be made into format, e.g. 'shortlog' and 'log' (and perhaps 'rss') for log views (this includes "log"/"shortlog" and "history" views), or 'html', 'opml' and 'plain'/'index' for "project_list". DISCUSSION encouraged. * Things like description or cloneurls (repourls) and further category should be perhaps available to set in repository config, not only from additional files in repository. Gitweb speed: * Ensure that gitweb is compatibile with mod_perl not only in Apache::Registry/ModPerl::Registry CGI script compatibility mode, but also as native mod_perl handler/script. Make it easy to use FastCGI instead of CGI (perhaps via CGI::Fast). This could be ensured by creating 'handler'/'main' method which does parameter reading, validation and dispatching action. Perhaps we should add gitweb_params subroutine, which given the names of parameters returns values of needed parameters (either as list of parameter names and returning list of parameters in order set by subroutine argument, or as hash with keys and undefined values and returning hash or hashref with values filled). The exception being project and action parameters, which must be accessed before dispatching action. We could make script options parameters my() again, and leave our() only for global variables which changes from invocation to invocation, like $project, $action, $git_dir etc. * Add new CORE GIT command, git-show-refs, which returns for given by glob set of refs required fields (specified by --format option), sorted by given field (specified by --sort option). This would speed up "tags" and "summary" views considerably. See Junio post in "[PATCH/RFC] gitweb: Great subroutines renaming" thread for proposed git-show-refs options. http://permalink.gmane.org/gmane.comp.version-control.git/25055 Message-Id: <7vejvsyum8.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> * Try to avoid unnecessary calls to git commands, try do do things using one command. For example instead of getting list of revisions from git-rev-list, then parsing commit after commit use one git-rev-list invocation to get and parse list of revisions. It would be easier if some CORE GIT commands, for example git-ls-tree, acquired --stdin option, similarly to git-diff-tree (and output revision before output for that revison, like git-diff-tree). * In the future, use Git.pm Improvements of existing views and features: * Make pickaxe search a feature (as it is expensive), and document existing search operators. Perhaps refactor git_search as well. * Make history follow renames. This could I think be done without CORE GIT support, but it would be better with it. The proposition is to add --follow option to git-rev-list (or -C, -M, -B options), which would make if follow renames in files in path limit; I think following renames with pathspec being glob is out, unless we expand glob to individual file names and then follow those, and that following directory renames would be very hard if not impossible. Additionally make git-rev-list output current path limit, in format suitable as argument for other git commands like git-diff-tree, i.e. <hash> -- <path limit> instead of current <hash> Make git-diff-tree at least accept and understand this kind of input also on stdin with --stdin option. * Perhaps add number of changed lines to the short information about blob (perhaps via title to patch/diff link?), and diffstat to "commitdiff_plain" view. * Parse $GIT_DIR/remotes/ to mark tracking branches in "heads" view, e.g. as a popup. New features: * Categories support (from gitweb-xmms2), although I'm not sure about adding yet another file "category" to git repository. Perhaps first part of dirname could serve as category name, or we could use gitweb.category configuration variable. * Code highlighting in blob view (from gitweb-xmms2), or to generalize to allow for generalized filter. The higlighter should have support for HTML support, it should always close elements before end of line, it would be better if it used CSS for styling, and it should accept file to highlight on standard input. gitweb-xmms2 uses Highlight http://www.andre-simon.de/ but GNU Highlight (src-hilite) could be used instead http://www.gnu.org/software/src-highlite/ * Committags support, i.e. extend hyperlinking commit sha1 to commit view to hyperlinking bug #nn/BUG(nn) to the proper bugtracker, in both commit message view and (harder to do properly) in commit title/subject line which is hyperlink itself. The problem is how to do this general enough... I have thought about structure somewhat similar to %feature hash, i.e. something like %commitfilter hash, with 'enabled', 'override', 'name', 'options' or something like that and of course 'sub' (as we probably would use $cgi->a(...) to construct hyperlink, and not simple regexp replacement. DISCUSSION needed. * Etags/Ctags/LXR based anchors in the blob view. In gitweb-xmms2 they use temporary file to avoid race condition for both etags and highlighting. Is it worth doing? GNU Highlight has ctags (encumberant-ctags) support built in, I don't know about Highlight. New views: * Reflog support: show history of branch. I'm not sure if it is worth doing, as of now reflogs are local matter, and doesn't get copied on push even to bare repository. * ViewVC-like "tree_blame" view. It probably would need CORE GIT support to have acceptable speed, although version using git-ls-tree wasn't that slow. Or at least git-ls-tree with --stdin support. * gitk-ish (qgit-ish) view, with graph showing branches forking and merging. Not that easy, but probably possible. In the future: * AJAX-ize parts of gitweb. Comments? Other ideas? <wishful thinking>Code?</wishful thinking> -- Jakub Narebski ShadeHawk on #git Poland -- VGER BF report: H 0 - 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