{"thread":{"id":"5457","subject":"[RFC] gitweb wishlist and TODO list","startedAt":"2006-09-02T16:17:08Z","lastAt":"2006-09-08T09:11:09Z","messageCount":10,"participants":["Jakub Narebski","Marco Costalba","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"26226","messageId":"200609021817.09296.jnareb@gmail.com","threadId":"5457","inReplyTo":null,"subject":"[RFC] gitweb wishlist and TODO list","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-02T16:17:08Z","receivedAt":"2006-09-02T16:17:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"This is second series of planned gitweb features. Still ideas for many \nof them come from xmms2's gitweb version, which can you see in work at\n  http://git.xmms.se/?p=gitweb-xmms2.git;a=summary\nSome of gitweb features like snapshot support and clone/fetch URL were \nimplemented, some of cleanup like refactoring navbar generation or \nputting CSS into separate style file too.\n\nI have put the list here for three reasons. First to get input which \nfeatures are most wanted, and to receive perhaps ideas for new \nfeatures. Second, to have TODO list, and receive input if somebody is \ndoing implementing some of the features to avoid duplicate work. Third, \nand most important, some of features needs discussion about _how_ to \nimplement them.\n\nCopy sent to Sham Chukoury, owner of gitweb-xmms2.\n\n\nCleanup, tidying, refactoring:\n* HTML code still needs cleanup. All elements should have be either\n  assigned class, or given unique id. Presentational elements like <i>\n  or <b> should be replaced by styling using CSS. Page should be divided\n  into block elements; avoid overuse of <br/>.\n\n* CSS cleanup. Names of classes should reflect intent, not be\n  replacement for presentational elements, or be incomprehensive:\n  e.g. classes age0, age1, age2, dark, light. padding: 8px; repeats many\n  times, perhaps it could be replaced by setting margin in encompassing\n  element, or via inheritance or additional class.\n\n* Separate generating link and related links to object \n  (e.g. \"blob | blame | history | raw\" for blob in \"tree\" view)\n  into subroutine, similarly to refactoring navbar. The problem is that\n  the set of links depends not only on the type of object, but also on\n  the action/view we are in, for example links to commit object might\n  be either \"commit | commitdiff\", or \"log | shortlog\" if the commit is\n  considered ref. DISCUSSION needed.\n\n* Collapse similar subroutines into one, e.g. git_blob and\n  git_blob_plain, and use parameter to set format. Perhaps instead of\n  having\n\tsub git_commitdiff_plain {\n\t\tgit_commitdiff('plain');\n\t}\n  we can simply use\n\tmy %actions = (\n\t\t# ...\n\t\t\"commitdiff_plain\" => sub { git_commitdiff('plain'); }\n\t\t# ...\n\t);\n  Which of this options is more readable, which one is faster?\n\n* Refactoring formatsnav similarly to commit/hashbase related main\n  navbar (upper part of navbar now). For blob it would be \"html\",\n  \"plain\", \"blame\", \"head\" (or \"base\"), optionally \"HEAD\", \"history\",\n  perhaps later \"highlight\". For tree it would be \"tree\", \"blame\" and\n  \"history\". For commit it would be \"html\", \"plain\", and \"combined\" \n  if applicable.\n\n* Perhaps some of the views should be made into format, e.g. 'shortlog'\n  and 'log' (and perhaps 'rss') for log views (this includes\n  \"log\"/\"shortlog\" and \"history\" views), or 'html', 'opml' and\n  'plain'/'index' for \"project_list\". DISCUSSION encouraged.\n\n* Things like description or cloneurls (repourls) and further category\n  should be perhaps available to set in repository config, not only from\n  additional files in repository.\n\n\nGitweb speed:\n* Ensure that gitweb is compatibile with mod_perl not only in\n  Apache::Registry/ModPerl::Registry CGI script compatibility mode,\n  but also as native mod_perl handler/script. Make it easy to use\n  FastCGI instead of CGI (perhaps via CGI::Fast).\n\n  This could be ensured by creating 'handler'/'main' method which\n  does parameter reading, validation and dispatching action. Perhaps\n  we should add gitweb_params subroutine, which given the names\n  of parameters returns values of needed parameters (either as list of\n  parameter names and returning list of parameters in order set by\n  subroutine argument, or as hash with keys and undefined values and\n  returning hash or hashref with values filled). The exception being\n  project and action parameters, which must be accessed before\n  dispatching action.\n\n  We could make script options parameters my() again, and leave our()\n  only for global variables which changes from invocation to invocation,\n  like $project, $action, $git_dir etc.  \n\n* Add new CORE GIT command, git-show-refs, which returns for given\n  by glob set of refs required fields (specified by --format option),\n  sorted by given field (specified by --sort option). This would speed\n  up \"tags\" and \"summary\" views considerably.\n\n  See Junio post in \"[PATCH/RFC] gitweb: Great subroutines renaming\"\n  thread for proposed git-show-refs options.\n    http://permalink.gmane.org/gmane.comp.version-control.git/25055\n    Message-Id: <7vejvsyum8.fsf@assigned-by-dhcp.cox.net>\n\n* Try to avoid unnecessary calls to git commands, try do do things\n  using one command. For example instead of getting list of revisions\n  from git-rev-list, then parsing commit after commit use one \n  git-rev-list invocation to get and parse list of revisions.\n\n  It would be easier if some CORE GIT commands, for example git-ls-tree,\n  acquired --stdin option, similarly to git-diff-tree (and output\n  revision before output for that revison, like git-diff-tree).\n\n* In the future, use Git.pm\n\n\nImprovements of existing views and features:\n* Make pickaxe search a feature (as it is expensive), and document\n  existing search operators. Perhaps refactor git_search as well.\n\n* Make history follow renames. This could I think be done without CORE\n  GIT support, but it would be better with it. The proposition is to add\n  --follow option to git-rev-list (or -C, -M, -B options), which would\n  make if follow renames in files in path limit; I think following\n  renames with pathspec being glob is out, unless we expand glob to\n  individual file names and then follow those, and that following\n  directory renames would be very hard if not impossible.\n\n  Additionally make git-rev-list output current path limit, in format\n  suitable as argument for other git commands like git-diff-tree, i.e.\n  \t<hash> -- <path limit>\n  instead of current\n  \t<hash>\n  Make git-diff-tree at least accept and understand this kind of input\n  also on stdin with --stdin option.\n\n* Perhaps add number of changed lines to the short information about\n  blob (perhaps via title to patch/diff link?), and diffstat to\n  \"commitdiff_plain\" view.\n\n* Parse $GIT_DIR/remotes/ to mark tracking branches in \"heads\" view,\n  e.g. as a popup.\n\n\nNew features:\n* Categories support (from gitweb-xmms2), although I'm not sure about\n  adding yet another file \"category\" to git repository. Perhaps first\n  part of dirname could serve as category name, or we could use\n  gitweb.category configuration variable.\n\n* Code highlighting in blob view (from gitweb-xmms2), or to generalize\n  to allow for generalized filter. The higlighter should have support\n  for HTML support, it should always close elements before end of line,\n  it would be better if it used CSS for styling, and it should accept\n  file to highlight on standard input. gitweb-xmms2 uses Highlight\n    http://www.andre-simon.de/\n  but GNU Highlight (src-hilite) could be used instead\n    http://www.gnu.org/software/src-highlite/\n\n* Committags support, i.e. extend hyperlinking commit sha1 to commit\n  view to hyperlinking bug #nn/BUG(nn) to the proper bugtracker, in both\n  commit message view and (harder to do properly) in commit\n  title/subject line which is hyperlink itself. The problem is how to do\n  this general enough...\n\n  I have thought about structure somewhat similar to %feature hash, i.e.\n  something like %commitfilter hash, with 'enabled', 'override', 'name',\n  'options' or something like that and of course 'sub' (as we probably\n  would use $cgi->a(...) to construct hyperlink, and not simple regexp\n  replacement.\n\n  DISCUSSION needed.\n\n* Etags/Ctags/LXR based anchors in the blob view. In gitweb-xmms2 they\n  use temporary file to avoid race condition for both etags and\n  highlighting. Is it worth doing? GNU Highlight has ctags\n  (encumberant-ctags) support built in, I don't know about Highlight.\n\n\nNew views:\n* Reflog support: show history of branch. I'm not sure if it is worth\n  doing, as of now reflogs are local matter, and doesn't get copied on\n  push even to bare repository.\n\n* ViewVC-like \"tree_blame\" view. It probably would need CORE GIT support\n  to have acceptable speed, although version using git-ls-tree wasn't\n  that slow. Or at least git-ls-tree with --stdin support.\n\n* gitk-ish (qgit-ish) view, with graph showing branches forking and\n  merging. Not that easy, but probably possible.\n\n\nIn the future:\n* AJAX-ize parts of gitweb.\n\n\nComments? Other ideas? <wishful thinking>Code?</wishful thinking>\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n\n-- \nVGER BF report: H 0\n"},{"id":"26233","messageId":"e5bfff550609021110x2fcfdc52r2cdce9c23ff46b14@mail.gmail.com","threadId":"5457","inReplyTo":"200609021817.09296.jnareb@gmail.com","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-09-02T18:10:01Z","receivedAt":"2006-09-02T18:10:01Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":">\n> * Code highlighting in blob view (from gitweb-xmms2), or to generalize\n>   to allow for generalized filter. The higlighter should have support\n>   for HTML support, it should always close elements before end of line,\n>   it would be better if it used CSS for styling, and it should accept\n>   file to highlight on standard input. gitweb-xmms2 uses Highlight\n>     http://www.andre-simon.de/\n>   but GNU Highlight (src-hilite) could be used instead\n>     http://www.gnu.org/software/src-highlite/\n>\n\nCurrent HEAD of qgit  (I plan to release the new version very shortly)\nuses GNU Highlight. I can say this tool is easy to use yet very\nflexible and configurable and, last but not the least, the developer\nis very responsive.\n\nMy two cents.\n\n  Marco\n\n-- \nVGER BF report: U 0.500001\n"},{"id":"26236","messageId":"edcm1v$24k$1@sea.gmane.org","threadId":"5457","inReplyTo":"200609021817.09296.jnareb@gmail.com","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-02T19:29:03Z","receivedAt":"2006-09-02T19:29:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"By the way, do the diff between arbitrary revisions (say, between two\nbranches/two refs) and between arbitrary versions of the same file would be\nuseful to have in gitweb?\n\n-- \nJakub Narębski\nPoland\n\n\n-- \nVGER BF report: U 0.5\n"},{"id":"26247","messageId":"e5bfff550609022126j1a79c750vb3aeea01cda10bac@mail.gmail.com","threadId":"5457","inReplyTo":"edcm1v$24k$1@sea.gmane.org","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-09-03T04:26:40Z","receivedAt":"2006-09-03T04:26:40Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:\n> By the way, do the diff between arbitrary revisions (say, between two\n> branches/two refs) and between arbitrary versions of the same file would be\n> useful to have in gitweb?\n>\n\nA nice tool, lot of ideas to steal ;-)\n\nhttp://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1\n\n-- \nVGER BF report: U 0.510515\n"},{"id":"26253","messageId":"ede765$b9u$2@sea.gmane.org","threadId":"5457","inReplyTo":"e5bfff550609022126j1a79c750vb3aeea01cda10bac@mail.gmail.com","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-03T09:27:36Z","receivedAt":"2006-09-03T09:27:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Marco Costalba wrote:\n\n> On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:\n>>\n>> By the way, do the diff between arbitrary revisions (say, between two\n>> branches/two refs) and between arbitrary versions of the same file would be\n>> useful to have in gitweb?\n>>\n> \n> A nice tool, lot of ideas to steal ;-)\n> \n> http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1\n\nFishEye? I haven't took the full tour, but the tool seems somewhat\nCVS centric, i.e. per file history, file description,...\n\nBut for example \"breadcrumbs\" idea for the file path (each segment of path\nbeing link to given (sub)directory) is a nice one. Although if I remember\ncorrectly the pathname (for files only) is currently hack to have somewhere\nlink to \"head\" version of current file in plain format.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n\n\n-- \nVGER BF report: U 0.910123\n"},{"id":"26254","messageId":"e5bfff550609030410h11469715m88e0b5fba09f2440@mail.gmail.com","threadId":"5457","inReplyTo":"ede765$b9u$2@sea.gmane.org","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-09-03T11:10:02Z","receivedAt":"2006-09-03T11:10:02Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 9/3/06, Jakub Narebski <jnareb@gmail.com> wrote:\n> Marco Costalba wrote:\n>\n> > On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:\n> >>\n> >> By the way, do the diff between arbitrary revisions (say, between two\n> >> branches/two refs) and between arbitrary versions of the same file would be\n> >> useful to have in gitweb?\n> >>\n> >\n> > A nice tool, lot of ideas to steal ;-)\n> >\n> > http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1\n>\n> FishEye? I haven't took the full tour, but the tool seems somewhat\n> CVS centric, i.e. per file history, file description,...\n>\n> But for example \"breadcrumbs\" idea for the file path (each segment of path\n> being link to given (sub)directory) is a nice one. Although if I remember\n> correctly the pathname (for files only) is currently hack to have somewhere\n> link to \"head\" version of current file in plain format.\n> --\n\nAlso the UI for diff between arbitrary revisions could be interesting.\n\n-- \nVGER BF report: U 0.791104\n"},{"id":"26263","messageId":"edee1h$u4f$1@sea.gmane.org","threadId":"5457","inReplyTo":"e5bfff550609030410h11469715m88e0b5fba09f2440@mail.gmail.com","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-03T11:24:36Z","receivedAt":"2006-09-03T11:24:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Marco Costalba wrote:\n\n> On 9/3/06, Jakub Narebski <jnareb@gmail.com> wrote:\n>> Marco Costalba wrote:\n>>\n>>> On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:\n>>>>\n>>>> By the way, do the diff between arbitrary revisions (say, between two\n>>>> branches/two refs) and between arbitrary versions of the same file\n>>>> would be useful to have in gitweb?\n>>>>\n>>>\n>>> A nice tool, lot of ideas to steal ;-)\n>>>\n>>>http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1\n>>\n>> FishEye? I haven't took the full tour, but the tool seems somewhat\n>> CVS centric, i.e. per file history, file description,...\n>>\n>> But for example \"breadcrumbs\" idea for the file path (each segment\n>> of path being link to given (sub)directory) is a nice one. Although \n>> if I remember correctly the pathname (for files only) is currently\n>> hack to have somewhere link to \"head\" version of current file in\n>> plain format. \n> \n> Also the UI for diff between arbitrary revisions could be interesting.\n\nThere is problem with git encouraging multiple branches and nonlinear\nhistory. While it would be fairly easy either to add Wiki-like (e.g.\nhttp://git.or.cz/gitwiki/ or http://en.wikipedia.org) radio-boxes to mark\nrevisions to compare, or add pull down menu to select revision (useless\nwith longer history) of a given file (we have diff-to-current in file\nhistory, by the way), the true power of selecting revisions to compare\nwould be when we would have graphical history visualizer built in, similar\nto gitk and qgit. \n\nBy the way, do you known any common Perl modules for generating PNG\n(graphs)?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n\n\n-- \nVGER BF report: S 0.995678\n"},{"id":"26553","messageId":"edqeco$ums$1@sea.gmane.org","threadId":"5457","inReplyTo":"200609021817.09296.jnareb@gmail.com","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-08T00:44:37Z","receivedAt":"2006-09-08T00:44:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> * Committags support, i.e. extend hyperlinking commit sha1 to commit\n>   view to hyperlinking bug #nn/BUG(nn) to the proper bugtracker, in both\n>   commit message view and (harder to do properly) in commit\n>   title/subject line which is hyperlink itself. The problem is how to do\n>   this general enough...\n> \n>   I have thought about structure somewhat similar to %feature hash, i.e.\n>   something like %commitfilter hash, with 'enabled', 'override', 'name',\n>   'options' or something like that and of course 'sub' (as we probably\n>   would use $cgi->a(...) to construct hyperlink, and not simple regexp\n>   replacement.\n\nI have very preliminary work, where gitweb uses @enabled_committags as list\nof committags to use, and %committags_info for actual committags info.\nExamples of committags includes current linking of commit sha1,\ngitweb-xmms2 linking of BUG(n) and FEATURE(n) to site-wide based URL\n(Mantis), and RELEASE x.y.z to site-wide based URL (Wiki); perhaps \"bug n\"\nto site-wide/project-wide URL (Bugzilla)... any other ideas?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26555","messageId":"7vzmdbp38k.fsf@assigned-by-dhcp.cox.net","threadId":"5457","inReplyTo":"edqeco$ums$1@sea.gmane.org","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-08T01:16:11Z","receivedAt":"2006-09-08T01:16:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> I have very preliminary work, where gitweb uses @enabled_committags as list\n> of committags to use, and %committags_info for actual committags info.\n> Examples of committags includes current linking of commit sha1,\n> gitweb-xmms2 linking of BUG(n) and FEATURE(n) to site-wide based URL\n> (Mantis), and RELEASE x.y.z to site-wide based URL (Wiki); perhaps \"bug n\"\n> to site-wide/project-wide URL (Bugzilla)... any other ideas?\n\nUse a regexp as %committags key and its value to be whatever\nthat takes the matched string and munge it into a URL form\nperhaps?  A site that does not have commit tags do not have any\nelement in that hash.\n"},{"id":"26576","messageId":"edrc2e$cpq$1@sea.gmane.org","threadId":"5457","inReplyTo":"7vzmdbp38k.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] gitweb wishlist and TODO list","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-08T09:11:09Z","receivedAt":"2006-09-08T09:11:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n>> I have very preliminary work, where gitweb uses @enabled_committags as list\n>> of committags to use, and %committags_info for actual committags info.\n>> Examples of committags includes current linking of commit sha1,\n>> gitweb-xmms2 linking of BUG(n) and FEATURE(n) to site-wide based URL\n>> (Mantis), and RELEASE x.y.z to site-wide based URL (Wiki); perhaps \"bug n\"\n>> to site-wide/project-wide URL (Bugzilla)... any other ideas?\n> \n> Use a regexp as %committags key and its value to be whatever\n> that takes the matched string and munge it into a URL form\n> perhaps?  A site that does not have commit tags do not have any\n> element in that hash.\n\nThe problem is when you have a bunch of projects, all server by the same \ngitweb, but otherwise unrelated, so needing different committags (e.g. one \nproject uses Mantis and needs \"BUG(n)\" and \"FEATURE(n)\", another uses \nBugzilla and needs \"bug nn\", yet another doesn't use any bugtracker).\nAnd for committag you would want also information if to use it in summary\n(title) in shortlog, head, history etc. views.\n\nBut this might be a good idea.\n\nWe loop over all enabled (active) committags.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}