{"thread":{"id":"23676","subject":"RFD: Shipping GitBrowser.js for instaweb","startedAt":"2010-05-02T16:25:36Z","lastAt":"2010-05-03T19:12:09Z","messageCount":4,"participants":["Michael J Gruber","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140785","messageId":"4BDDA780.7090500@drmicha.warpmail.net","threadId":"23676","inReplyTo":null,"subject":"RFD: Shipping GitBrowser.js for instaweb","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-02T16:25:36Z","receivedAt":"2010-05-02T16:25:36Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Heya ;)\n\nI was wondering whether it would make sense to ship GitBrowser.js with\nGit and how much it would take to do so.\n\nMy personal answer to the 1st Q is Yes: instaweb as well as simple\ngitweb installs would benefit from a graphical DAG viewer.\n\nAbout the required effort I have no clue: I find it difficult to see\nthrough which repo contains current gitweb, current repo.or.cz mods, and\nespecially the GitBrowser integration bits. Maybe we could ship the\nintegration bits without the actual GitBrowser if that is more feasible?\n\nMichael\n"},{"id":"140794","messageId":"m3wrvmf4ei.fsf@localhost.localdomain","threadId":"23676","inReplyTo":"4BDDA780.7090500@drmicha.warpmail.net","subject":"Re: RFD: Shipping GitBrowser.js for instaweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-05-02T20:14:27Z","receivedAt":"2010-05-02T20:14:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael J Gruber writes:\n\n> I was wondering whether it would make sense to ship GitBrowser.js with\n> Git and how much it would take to do so.\n> \n> My personal answer to the 1st Q is Yes: instaweb as well as simple\n> gitweb installs would benefit from a graphical DAG viewer.\n> \n> About the required effort I have no clue: I find it difficult to see\n> through which repo contains current gitweb, current repo.or.cz mods, and\n> especially the GitBrowser integration bits. Maybe we could ship the\n> integration bits without the actual GitBrowser if that is more feasible?\n\nThe integration parts are actually present in gitweb, I think. It is\na matter of configuration to enable 'graphiclog' link like in\nhttp://repo.or.cz\n\nGitBrowser.js is not, I think, the best solution for having graphical\nhistory in gitweb, but would do...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"140815","messageId":"4BDE81D8.8070505@drmicha.warpmail.net","threadId":"23676","inReplyTo":"m3wrvmf4ei.fsf@localhost.localdomain","subject":"Re: RFD: Shipping GitBrowser.js for instaweb","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-03T07:57:12Z","receivedAt":"2010-05-03T07:57:12Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jakub Narebski venit, vidit, dixit 02.05.2010 22:14:\n> Michael J Gruber writes:\n> \n>> I was wondering whether it would make sense to ship GitBrowser.js with\n>> Git and how much it would take to do so.\n>>\n>> My personal answer to the 1st Q is Yes: instaweb as well as simple\n>> gitweb installs would benefit from a graphical DAG viewer.\n>>\n>> About the required effort I have no clue: I find it difficult to see\n>> through which repo contains current gitweb, current repo.or.cz mods, and\n>> especially the GitBrowser integration bits. Maybe we could ship the\n>> integration bits without the actual GitBrowser if that is more feasible?\n> \n> The integration parts are actually present in gitweb, I think. It is\n> a matter of configuration to enable 'graphiclog' link like in\n> http://repo.or.cz\n> \n> GitBrowser.js is not, I think, the best solution for having graphical\n> history in gitweb, but would do...\n\nAfter having a more thorough look at it I agree... We don't want to\ninflate $GIT_DIR/gitweb more than necessary.\n\nBut what are the alternatives? Something svg/canvas would be nice, I\nguess. The ruby frontends with graphlog don't convince me at all\n(neither performance-wise nor layout-wise).\n\nMichael\n"},{"id":"140844","messageId":"201005032112.10682.jnareb@gmail.com","threadId":"23676","inReplyTo":"4BDE81D8.8070505@drmicha.warpmail.net","subject":"Re: RFD: Shipping GitBrowser.js for instaweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-05-03T19:12:09Z","receivedAt":"2010-05-03T19:12:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 3 May 2010, Michael J Gruber wrote:\n> Jakub Narebski venit, vidit, dixit 02.05.2010 22:14:\n>> Michael J Gruber writes:\n>> \n>>> I was wondering whether it would make sense to ship GitBrowser.js with\n>>> Git and how much it would take to do so.\n>>>\n>>> My personal answer to the 1st Q is Yes: instaweb as well as simple\n>>> gitweb installs would benefit from a graphical DAG viewer.\n>>>\n>>> About the required effort I have no clue: I find it difficult to see\n>>> through which repo contains current gitweb, current repo.or.cz mods, and\n>>> especially the GitBrowser integration bits. Maybe we could ship the\n>>> integration bits without the actual GitBrowser if that is more feasible?\n>> \n>> The integration parts are actually present in gitweb, I think. It is\n>> a matter of configuration to enable 'graphiclog' link like in\n>> http://repo.or.cz\n>> \n>> GitBrowser.js is not, I think, the best solution for having graphical\n>> history in gitweb, but would do...\n> \n> After having a more thorough look at it I agree... We don't want to\n> inflate $GIT_DIR/gitweb more than necessary.\n\nEspecially that GitBrowser.js (git-browser) does drawing in *JavaScript*,\nand requires (included) extra wz_jsgraphics.js JavaScript library\n(Walter Zorn's High Performance JavaScript Graphics Library).\n\n> \n> But what are the alternatives? Something svg/canvas would be nice, I\n> guess. The ruby frontends with graphlog don't convince me at all\n> (neither performance-wise nor layout-wise).\n\n1. Using SVG/canvas (probably with Flash as fallback for those web \n browser that do not have support for canvas element and/or SVN)\n seems like overkill for gitk / qgit / \"git log --graph\" equivalent\n for gitweb... well, unless for something like interactive 'Network'\n graph on GitHub, see e.g. http://github.com/jquery/jquery/network\n\n2. Gitweb could generate required images on-the-fly using one of graphics\n modules like GD (uses gd library), Imaginer, or Image::Imlib2 (uses\n imlib2 library). GD is, I think, most commonly used and available.\n We would want to make it conditional on GD (and gd library) being\n available.\n\n3. Gitweb could use some ready images, which would be composed to form\n graphical representation of history; it would probably use CSS to\n change color (and require support for opacity in CSS or transparent\n layer in PNG). See also 4.\n\n4. Gitweb could use Unicode characters for tree graphics like git-forest\n (http://dev.medozas.de/gitweb.cgi?p=hxtools;a=blob_plain;f=bin/git-forest)\n does (I think it uses box drawing characters U+2500-257F). We could\n even borrow some code from git-forest, which is also in Perl \n (by Jan Engelhardt).\n\n5. Gitweb could use ASCII-art for drawing history, like \"git log --graph\"\n does... perhaps even by directly using (and probably postprocessing)\n git-log / git-rev-list output with the '--graph' option. It could\n change (transform) ASCII-art to Unicode box drawing characters.\n\n-- \nJakub Narebski\nPoland\n"}]}