git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [RFC] gitweb wishlist and TODO list
@ 2006-09-03 11:52 Jakub Narebski
  2006-09-03 12:18 ` Marco Costalba
  0 siblings, 1 reply; 64+ messages in thread
From: Jakub Narebski @ 2006-09-03 11:52 UTC (permalink / raw)
  To: git, Marco Costalba

Marco Costalba wrote:

> On 9/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Marco Costalba wrote:
>>
>>> On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>
>>>> By the way, do the diff between arbitrary revisions (say, between two
>>>> branches/two refs) and between arbitrary versions of the same file
>>>> would be useful to have in gitweb?
>>>>
>>>
>>> A nice tool, lot of ideas to steal ;-)
>>>
>>>http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1
>>
>> FishEye? I haven't took the full tour, but the tool seems somewhat
>> CVS centric, i.e. per file history, file description,...
>>
>> But for example "breadcrumbs" idea for the file path (each segment
>> of path being link to given (sub)directory) is a nice one. Although 
>> if I remember correctly the pathname (for files only) is currently
>> hack to have somewhere link to "head" version of current file in
>> plain format. 
> 
> Also the UI for diff between arbitrary revisions could be interesting.

There is problem with git encouraging multiple branches and nonlinear
history. While it would be fairly easy either to add Wiki-like (e.g.
http://git.or.cz/gitwiki/ or http://en.wikipedia.org) radio-boxes to mark
revisions to compare, or add pull down menu to select revision (useless
with longer history) of a given file (we have diff-to-current in file
history, by the way), the true power of selecting revisions to compare
would be when we would have graphical history visualizer built in, similar
to gitk and qgit. 

By the way, do you known any common Perl modules for generating PNG
(graphs)?

P.S. This message seems to hit VGER BOGOfilter... ehhh...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git



-- 
VGER BF report: S 0.999997

^ permalink raw reply	[flat|nested] 64+ messages in thread
* [RFC] gitweb wishlist and TODO list
@ 2008-09-25 10:30 Jakub Narebski
  2008-09-25 11:08 ` Pedro Melo
                   ` (3 more replies)
  0 siblings, 4 replies; 64+ messages in thread
From: Jakub Narebski @ 2008-09-25 10:30 UTC (permalink / raw)
  To: git; +Cc: Petr Baudis

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

^ permalink raw reply	[flat|nested] 64+ messages in thread
* [RFC] gitweb wishlist and TODO list
@ 2008-04-25 13:14 Jakub Narebski
  0 siblings, 0 replies; 64+ messages in thread
From: Jakub Narebski @ 2008-04-25 13:14 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 64+ messages in thread
* [RFC] gitweb wishlist and TODO list
@ 2006-10-09 12:49 Jakub Narebski
  2006-10-10  1:47 ` Luben Tuikov
                   ` (3 more replies)
  0 siblings, 4 replies; 64+ messages in thread
From: Jakub Narebski @ 2006-10-09 12:49 UTC (permalink / raw)
  To: git

There is a new part of gitweb TODO list and wishlist; planned features and
features it would be nice to have. If you have new ideas, if you want some
features to be implemented first, if you use some web interface to some SCM
you like, please do contribute.

I've tried to divide this TODO/wishlist into categories.


1. Cleanups and refactoring

 * HTML and CSS cleanup. All (or almost all) styling should be done using
   CSS, and not embedded style or presentation elements. All HTML elements
   except perhaps a few should have either class attribute (if such
   element can be multiple times on page) or id attribute (if there can be
   only one such element). Perhaps some class attributes should be changed
   to id attributes. Gitweb has much improved from the incorporation in
   this area.

 * CSS refactoring. Try to avoid repeating the same styling, using
   combination of descendant and _child_ selectors, perhaps also
   adjacent sibling selector and attribute/attribute value selector.
   Perhaps large reorganization patch (moving contents within CSS and adding
   comments) is to be done...

 * Code refactoring. Separate/refactor common parts and put them into
   separate subrotines OR collapse similar subrotines into one subroutine
   with an argument selecting the case. For example git_blob and
   git_blob_plain could be collapsed; git_shortlog, git_tags/git_heads,
   git_log, git_history do similar work. When the new
   --grep/--author/--commiter options to git-rev-list hits released version,
   perhaps also git_search could be put together with the previous set.
   git_rss does similar work as a git_summary.

 * Refactor printing related links (like "blame | history | raw" for blob
   entries in tree view) into separate subroutine. The list depends both on
   the kind of object pointed, and on the current action/view.

 * Perhaps refactor reading and validation of parameters, except the ones
   used for dispatch i.e. project and action parameters, into separate
   subroutine
 
        my ($hash, $hash_base) = gitweb_params('hash', 'hash_base');    

   I'm not sure if it is/would be usefull.


2. Git.pm-ish (subroutines which in generalized version are/could be
   in Git.pm)
 
 * Refactor calling a git command and reading it's output into separate
   subroutine git_command/git_pipe, so for example if someone _has_ to use
   gitweb with ancient Perl version which does not understand list version
   of magic "-|" open could do it changing only one subroutine. Well, we can
   use Git.pm when it hits main release.

 * Add subroutine/subroutines, which given a full name of ref, returns
   either another ref if input ref was symlink/symref, or hash of the
   pointed object, and which work not only with ordinary loose refs, but
   also with symlinks, symrefs (up to some level of recursion) and packed
   refs. All without calling any git command. But I guess that currently
   it is not needed at all.

 * Add simplified git config file parser, which would _read_ only gitweb
   entries (and convert them to bool/int if necessary). With this we could
   move description, category, export_ok, .hide, cloneurl to config file,
   instead of cluttering $GIT_DIR. Or just make it an option (read file
   first, if it doesn't exist try config file).

 * Parsing of remotes/ files _and_ equivalent config entries, for adding
   information (tooltip?) about tracking branches in heads view, and for
   adding information about given subdirectory in refs/remotes/ (see below).


3. Optimizing gitweb

 * Use git-for-each-ref (when it hits released version) to speed up of
   generation of summary, heads and tags views. It would also enable the
   option of having most recent commit date in projects list view, and not
   most recent commit in current branch (in HEAD).
 
 * Add better support for mod_perl, e.g. $r->path_info(), via checking for
   MOD_PERL enviromental variable.

 * Better support for mod_perl/FastCGI, perhaps wrapping the changeable part
   into gitweb_handler subroutine, and calling it.


4. New features

 * Add support for other directories in $refs/ besides "heads" and
   "tags" directories, for example refs/remotes/ generated when cloning with
   --use-separate-remote option. On short TODO list.

 * Add categories support a la gitweb-xmms2 to the projects list view (and
   perhaps also OPML); perhaps with option to use first part of path to
   repository as category.

 * Code highlighting (or generic filter) support in blob view, perhaps as
   a feature. Proposed tools for generating syntax highlighting include
   Highlight (http://www.andre-simon.de) and GNU Source Highlight
   (http://www.gnu.org/software/src-highlite) a la gitweb-xmms2.
   Gitweb-xmms2 uses Highlight, and due to the tags support uses temporary
   files. I think that CSS for code highlighting should be in separate file,
   and that selecting syntax to use should be done using mime.types like
   file rather than gitweb-xmms2 internal configuration (hash of
   extensions).

 * Committags support from gitweb-xmms2 in commit, commitdiff, log views and
   in the top commit summary/title link on most pages. There was preliminary
   patch on git mailing list for committags support (more general than
   the support in gitweb-xmms2), with current commitsha link (now in
   format_log_line_html) implemented as committag. Junio had quite
   a good idea how to avoid having to do committags _after_ HTML escaping,
   and how to stack committags. I'm not sure if it wouldn't be better to try
   to do all committags in one go, instead of stacking. Perhaps also commit
   message "syntax highlighting" (i.e. highlighting signoff lines) and empty
   lines simplification should be done using committags.

 * Crossreferencing in blob view. Gitweb-xmms2 uses if I remember correctly
   etags to generate anchors and to generate hyperlinks to definition of
   function. GNU Highlight can use encumberant-tags IIRC. Both need I think
   temporary files for index. Perhaps this should be done rather as a part
   of gitweb/git integration with LXR Cross Referencer. 

   Do you know other projects that could be used instead of etags here?

   I'm not sure if it is worth to pursue implementing it now.

 * Improve blame view, making use of --porcelain option to git-blame (for
   later). Perhaps change blame view from table based one to div based one.
   Use different colors for different commits (graph coloring problem).

 * Perhaps add some kind of finding closest preceding/following tag. and on
   which branch we are on. Tempered of course by the concerns of
   performance. What is possible for locally run history browser like gitk
   or qgit, might be not feasible on server run web interface.

 * Add information from remotes/ to heads view, for example the following
     tracks branch 'master' of git://git.kernel.org/pub/scm/git/git (origin)
   as a tooltip for 'origin' branch. But what if one branch tracks more than
   one remote? Needs to use also config file.

 * Support for tracking renames in history view. Simple rename tracking
   I think could be done directly in gitweb; more advanced would need
   --follow option (i.e. core git improvement).

 * log/shortlog should be a format, so we could have log-like history, tags,
   heads views.

 * add summary of number of lines changed for each file (a la darcsview)
   in the difftree part of commit and *diff* views, e.g.

        blame.c   +1 -0  diff | history | blame

   or something like that.

 * add extended header to the commitdiff and perhaps blobdiff views,
   hyperlinked. _This_ would add some patches to commitdiff view, which are
   now IIRC visible only in difftree part now.

 * enable sorting tags/heads view by name instead of sorting it by date.


5. New views

 * Reflog view (most probably limited to heads only). I'm not sure if it is
   worth time spend on calling git commands to mark unreachable commits for
   example using strikethrough, and hyperlink reachable. Any ideas how such
   a view should look like?

 * ViewVC-like tree-blame view. There was RFC patch adding tree_blame view
   some time ago here, on git mailing list. The main problem of course is
   performance. We could implement tree_blame purely in gitweb as it was
   done in mentioned patch (having --stdin option to git-ls-tree would
   help), or add new core command/extend git-blame for directories. There is
   also a question if we want to find blame for tree entries, or not.

 * "List of the files in given directory, touched by given commit"

 * Perhaps ad Atom feed support as an alternative to RSS, and XOXO as an
   alternative to OPML.

 * Graph of number of changed files in given branch; probably should be
   cached.


X. Proposed improvements to core git commands
 * add --stdin option to git-ls-tree, a la --stdin option to git-diff-tree.
 * add --follow option to git-rev-list, allow to provide path limiter via
   stdin (with --stdin option) in git-diff-tree
 * add --numstat option to git-diff; currently only git-apply has it.


Thoughts? Comments?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 64+ messages in thread
* [RFC] gitweb wishlist and TODO list
@ 2006-09-02 16:17 Jakub Narebski
  2006-09-02 18:10 ` Marco Costalba
                   ` (2 more replies)
  0 siblings, 3 replies; 64+ messages in thread
From: Jakub Narebski @ 2006-09-02 16:17 UTC (permalink / raw)
  To: git

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@assigned-by-dhcp.cox.net>

* 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

^ permalink raw reply	[flat|nested] 64+ messages in thread
* [RFC] gitweb wishlist and TODO list
@ 2006-06-20 16:51 Jakub Narebski
  2006-06-20 17:33 ` Carl Worth
                   ` (6 more replies)
  0 siblings, 7 replies; 64+ messages in thread
From: Jakub Narebski @ 2006-06-20 16:51 UTC (permalink / raw)
  To: git

I am planning on copying features from xmms2's gitweb version 
to git's gitweb, and introducing new ones.

My gitweb can be seen at http://front.fuw.edu.pl/cgi-bin/jnareb/gitweb.cgi
Fetch from http://front.fuw.edu.pl/jnareb/scm/git.git/ (not checked!)


* HTML cleanup - ongoing process of replacing embedded style information
  with CSS styling, adding classes and ids to elements. This is independent 
  on other changes. On top of 'next', as it needs style in separate CSS
  file gitweb.css.

* Storing site-wide gitweb configuration in separate gitweb.conf file.
  Needs GIT_CONFIG patch. Not implemented yet.

  Bootstrapping: gitweb would need location of configuration file.
  Has to be changed in gitweb.cgi itself. Additionally gitexecdir or
  git in PATH is needed to be able to run git-repo-config to read config;
  the solution might be home-grown "parser" to find gitexecdir only.

  Both could be set from Makefile at install stage.

* Add git fetch URL to the project page from gitweb-xmms2. Needs site-wide
  base_url, which need not to be set as there is sane default: use base 
  of gitweb URL.

  Is it useful to allow repository configuration to override it?

* Support for categories from gitweb-xmms2. We can alternatively use
  directory structure of git projects displayed by gitweb as categories.
  Needs I think some site-wide configuration.

  Question: where store categories? .git/category, like .git/description?
  Use gitweb.category key? If yes, do convert description to repository key,
  or perhaps use gitweb.descriptionfile? What should be priority of those
  options if both are set: use repo-config for short (in project listing 
  and in page footer), and from file for long description on project page?
  What if they don't match?

* Refactor dispatch from if...elsif...else construction 
  to using 'name' => \&sub hash.

* Refactor generation of navigation bar. There are at least two
  implementations of that. With hash dispatch it would be easy to
  list all possibilities.

* Add (of course optional, like blame support) snapshot support. There are
  at least two different implementations. I'd prefer to do without second
  CGI script, but perhaps this is better from the performance point of view.
  gitweb-xmms2 has snapshot.cgi in Python: should it be rewritten in Perl?

* Code highlighting for plain view for blobs. gitweb-xmms2 did that using
  GNU highlight program and some embedded configuration (filename regexp to
  syntax used). More generic: run some post-processing. Configurable
  globally (perhaps separate "syntax type" filename or file magic mapping),
  and enabled per repository (default off).

* gitweb-xmms2 has something called committags support: it means that
  'BUG(n)', 'FEATURE(n)' and 'RELEASE: xx' in commit message are turned into
  bugtracker (Mantis for xmms2) or wiki links. It is extension of turning
  sha1-ids into references. Probably needs some extra configuration file,
  and some per repository configuration. Of course we want to support not
  only Mantis, but also e.g. Bugzilla (e.g. Linux kernel) and conventions
  for marking bugs therein.

* gitweb-xmms2 has also etags based anchors to mark function definitions 
  in blob view. I'm not sure it would be that usefull. LXR equivalent,
  perhaps...


Which of those should be implemented first?

Any further ideas for other useful features?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 64+ messages in thread
end of thread, other threads:[~2008-10-01  8:41 UTC | newest]

Thread overview: 64+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-03 11:52 [RFC] gitweb wishlist and TODO list Jakub Narebski
2006-09-03 12:18 ` Marco Costalba
2006-09-03 12:38   ` Jakub Narebski
  -- strict thread matches above, loose matches on Subject: below --
2008-09-25 10:30 Jakub Narebski
2008-09-25 11:08 ` Pedro Melo
2008-09-25 12:23   ` Jakub Narebski
2008-09-25 14:45     ` Pedro Melo
2008-09-25 21:23       ` Jakub Narebski
2008-09-25 13:19 ` Wincent Colaiuta
2008-09-25 13:33   ` Petr Baudis
2008-09-25 15:41   ` Jakub Narebski
2008-09-28 10:01 ` Jakub Narebski
2008-09-28 21:18   ` Petr Baudis
2008-10-01  8:40 ` Ask Bjørn Hansen
2008-04-25 13:14 Jakub Narebski
2006-10-09 12:49 Jakub Narebski
2006-10-10  1:47 ` Luben Tuikov
2006-10-10  8:54   ` Jakub Narebski
2006-10-11  5:52 ` Junio C Hamano
2006-10-11  9:20   ` Jakub Narebski
2006-10-12 10:03   ` Junio C Hamano
2006-10-13 19:55     ` Jakub Narebski
2006-10-11 15:09 ` Jakub Narebski
2006-10-11 23:05 ` Jakub Narebski
2006-09-02 16:17 Jakub Narebski
2006-09-02 18:10 ` Marco Costalba
2006-09-02 19:29 ` Jakub Narebski
2006-09-03  4:26   ` Marco Costalba
2006-09-03  9:27     ` Jakub Narebski
2006-09-03 11:10       ` Marco Costalba
2006-09-03 11:24         ` Jakub Narebski
2006-09-08  0:44 ` Jakub Narebski
2006-09-08  1:16   ` Junio C Hamano
2006-09-08  9:11     ` Jakub Narebski
2006-06-20 16:51 Jakub Narebski
2006-06-20 17:33 ` Carl Worth
2006-06-20 17:46   ` Jakub Narebski
2006-06-20 17:55     ` Petr Baudis
2006-06-20 18:34       ` Jakub Narebski
2006-06-20 18:40         ` Petr Baudis
2006-06-21 14:52       ` Jakub Narebski
2006-06-20 19:33 ` Martin Langhoff
2006-06-20 19:56   ` Jakub Narebski
2006-06-20 21:17     ` Martin Langhoff
2006-07-01 10:35       ` Paul Mackerras
2006-06-21 13:05   ` Dennis Stosberg
2006-06-21 13:30     ` Jakub Narebski
2006-06-22 10:00       ` Dennis Stosberg
2006-06-22 14:47         ` Ryan Anderson
2006-06-21 16:45     ` Ryan Anderson
2006-06-21 17:36       ` Jakub Narebski
2006-06-20 19:46 ` Junio C Hamano
2006-06-20 20:10 ` Petr Baudis
2006-06-20 20:59   ` Jakub Narebski
2006-06-20 21:25 ` Petr Baudis
2006-06-20 21:53 ` Thomas Glanzmann
2006-06-21  8:56   ` Josef Weidendorfer
2006-06-21  9:15     ` Jakub Narebski
2006-06-21  9:57       ` Josef Weidendorfer
2006-06-21 13:53         ` Jakub Narebski
     [not found]           ` <200606211802.41071.Josef.Weidendorfer@gmx.de>
2006-06-21 16:38             ` Jakub Narebski
2006-06-21 20:35               ` Josef Weidendorfer
2006-06-22  9:01 ` Jakub Narebski
2006-06-22  9:14   ` Junio C Hamano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).