[RFC] gitweb wishlist and TODO list
From: Jakub Narebski <hidden>
Date: 2016-06-15 22:42:38
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: [off-list ref]
* 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