{"thread":{"id":"8119","subject":"suggestions for gitweb","startedAt":"2007-05-12T20:55:30Z","lastAt":"2007-05-15T15:46:13Z","messageCount":21,"participants":["Michael Niedermayer","Junio C Hamano","Aaron Gray","Jakub Narebski","Lars Hjemli","Petr Baudis","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"41970","messageId":"20070512205529.GS14859@MichaelsNB","threadId":"8119","inReplyTo":null,"subject":"suggestions for gitweb","fromName":"Michael Niedermayer","fromEmail":"michaelni@gmx.at","sentAt":"2007-05-12T20:55:30Z","receivedAt":"2007-05-12T20:55:30Z","isPatch":false,"sender":{"key":"michaelni@gmx.at","avatar":null},"body":"Hi\n\nAs we are switching from svn to git, we also have to switch from viewvc to\ngitweb (or similar) and so ive thought id submit a short list of things\nive noticed in gitweb which i belive could be improved ...\n\n* gitweb uses many terms which are new to a non git user, and while\n  devlopers who work on ffmpeg will very likely very quickly have\n  figured out the meaning of all of them. i think simple users who just\n  want to browse the ffmpeg code will have their problems, so i belive \n  a small help text linked to from all pages which contains a short\n  definition of all the git(web) specific terms would be very helpfull\n  something like\n    blob        - file      at a specific revission/date\n    tree        - directory at a specific revission/date\n    (short) log - project wide commit log\n    history     - short log equivalent for a file or directory\n    ...\n\n* The color of adjacent blame \"hunks\" is so similar that its\n  indistinguishable on my notebook TFT when iam looking at it from slightly\n  above\n\n* The blame page shows the SHA1 for each hunk and IMHO thats the last thing\n  i would want to see first, id be much more interrested in by whom and\n  when a given change was done, iam wondering in which case the SHA1 would\n  be usefull? copy-paste onto your command line git tools but then why\n  use gitweb at all, 'git blame' would make more sense IMHO and a simple\n  click would reveal the sha1 with more info anyway ...\n\n* i either cant find the long history for a file or there is none (\"history\"\n  is like \"short log\" and \"log\" is not file specific) a \"long history\" link\n  in addition to \"history\" would be nice\n\n* on the history page there are \"blob\", \"commitdiff\" and \"diff to current\"\n  the obvious missing one is \"diff to previous\" which would be the diff to\n  the previous blob of this file\n\n* the history/log pages could contain some statistics for the commits like\n  the number of files changed and lines added/removed\n\n-- \nMichael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB\n\nit is not once nor twice but times without number that the same ideas make\ntheir appearance in the world. -- Aristotle\n"},{"id":"41976","messageId":"7v8xbtwtsy.fsf@assigned-by-dhcp.cox.net","threadId":"8119","inReplyTo":"20070512205529.GS14859@MichaelsNB","subject":"Re: suggestions for gitweb","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-12T22:39:25Z","receivedAt":"2007-05-12T22:39:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Niedermayer <michaelni@gmx.at> writes:\n\n> * gitweb uses many terms which are new to a non git user, and while\n>   devlopers who work on ffmpeg will very likely very quickly have\n>   figured out the meaning of all of them. i think simple users who just\n>   want to browse the ffmpeg code will have their problems, so i belive \n>   a small help text linked to from all pages which contains a short\n>   definition of all the git(web) specific terms would be very helpfull\n>   something like\n>     blob        - file      at a specific revission/date\n>     tree        - directory at a specific revission/date\n>     (short) log - project wide commit log\n>     history     - short log equivalent for a file or directory\n\nComing fron non-CVS camp, I think changing this to non-git terms\nis very harmful than educating users who are migrating from\nother systems.\n\n> * The color of adjacent blame \"hunks\" is so similar that its\n>   indistinguishable on my notebook TFT when iam looking at it from slightly\n>   above\n\nThis is more or less intentional to make the difference not too\ndistracting.  I thought it was controlled via css which\nsomething you can use browser side tricks to suite your taste?\n\n> * The blame page shows the SHA1 for each hunk and IMHO thats the last thing\n>   i would want to see first, id be much more interrested in by whom and\n>   when a given change was done, iam wondering in which case the SHA1 would\n>   be usefull? copy-paste onto your command line git tools but then why\n>   use gitweb at all, 'git blame' would make more sense IMHO and a simple\n>   click would reveal the sha1 with more info anyway ...\n\nThey serve no purpose other than showing something to click on,\nand allow you to hover over (some people argued in the past\nthat they recognize certain commit object names, but honestly I\nwould not believe them).  However, I do not think there are much\nbetter alternatives.  Try coming up with a different \"label\"\nstring that is of uniform length across commits, and does not\nchew up too much screen real estate.\n\n> * i either cant find the long history for a file or there is none (\"history\"\n>   is like \"short log\" and \"log\" is not file specific) a \"long history\" link\n>   in addition to \"history\" would be nice\n\nProbably.\n\n> * on the history page there are \"blob\", \"commitdiff\" and \"diff to current\"\n>   the obvious missing one is \"diff to previous\" which would be the diff to\n>   the previous blob of this file\n\nIsn't that commitdiff, or commitdiff on that page does not limit\nthe diff to the blob?\n\n> * the history/log pages could contain some statistics for the commits like\n>   the number of files changed and lines added/removed\n\nProbably.\n\nThe three last items should be relatively easy, if somebody is\ninterested.  Pasky, Jakub, what do you think?\n"},{"id":"41983","messageId":"1f3701c794eb$5ff781b0$0200a8c0@AMD2500","threadId":"8119","inReplyTo":"7v8xbtwtsy.fsf@assigned-by-dhcp.cox.net","subject":"Re: suggestions for gitweb","fromName":"Aaron Gray","fromEmail":"angray@beeb.net","sentAt":"2007-05-12T23:15:01Z","receivedAt":"2007-05-12T23:15:01Z","isPatch":false,"sender":{"key":"angray@beeb.net","avatar":null},"body":">> * the history/log pages could contain some statistics for the commits \n>> like\n>>   the number of files changed and lines added/removed\n>\n> Probably.\n>\n> The three last items should be relatively easy, if somebody is\n> interested.  Pasky, Jakub, what do you think?\n\nI would like to see lines of code and file sizes too.\n\nAaron\n"},{"id":"41988","messageId":"20070513000151.GT14859@MichaelsNB","threadId":"8119","inReplyTo":"7v8xbtwtsy.fsf@assigned-by-dhcp.cox.net","subject":"Re: suggestions for gitweb","fromName":"Michael Niedermayer","fromEmail":"michaelni@gmx.at","sentAt":"2007-05-13T00:01:52Z","receivedAt":"2007-05-13T00:01:52Z","isPatch":false,"sender":{"key":"michaelni@gmx.at","avatar":null},"body":"Hi\n\nOn Sat, May 12, 2007 at 03:39:25PM -0700, Junio C Hamano wrote:\n> Michael Niedermayer <michaelni@gmx.at> writes:\n> \n> > * gitweb uses many terms which are new to a non git user, and while\n> >   devlopers who work on ffmpeg will very likely very quickly have\n> >   figured out the meaning of all of them. i think simple users who just\n> >   want to browse the ffmpeg code will have their problems, so i belive \n> >   a small help text linked to from all pages which contains a short\n> >   definition of all the git(web) specific terms would be very helpfull\n> >   something like\n> >     blob        - file      at a specific revission/date\n> >     tree        - directory at a specific revission/date\n> >     (short) log - project wide commit log\n> >     history     - short log equivalent for a file or directory\n> \n> Coming fron non-CVS camp, I think changing this to non-git terms\n> is very harmful than educating users who are migrating from\n> other systems.\n\nyou must missunderstand me :(\ni want to educate them, but i cannot as iam not speaking about ffmpeg\ndevelopers/contributors but rather random people who are curious and \nwant to take a look at the ffmpeg source\n\nfor them a simple help link similar to \"ViewVC Help\" which viewvc has\non the bottom right of its pages would be great IMHO\nalso the text above is a pure random suggestion by a svn user and was\nnot intended to redefine any git terms\n\n\n> \n> > * The color of adjacent blame \"hunks\" is so similar that its\n> >   indistinguishable on my notebook TFT when iam looking at it from slightly\n> >   above\n> \n> This is more or less intentional to make the difference not too\n> distracting.  I thought it was controlled via css which\n> something you can use browser side tricks to suite your taste?\n\ni sure can, i just thought the default was less than optimal\n\n\n> \n> > * The blame page shows the SHA1 for each hunk and IMHO thats the last thing\n> >   i would want to see first, id be much more interrested in by whom and\n> >   when a given change was done, iam wondering in which case the SHA1 would\n> >   be usefull? copy-paste onto your command line git tools but then why\n> >   use gitweb at all, 'git blame' would make more sense IMHO and a simple\n> >   click would reveal the sha1 with more info anyway ...\n> \n> They serve no purpose other than showing something to click on,\n> and allow you to hover over (some people argued in the past\n> that they recognize certain commit object names, but honestly I\n> would not believe them).  However, I do not think there are much\n> better alternatives.  Try coming up with a different \"label\"\n> string that is of uniform length across commits, and does not\n> chew up too much screen real estate.\n\ntrivial\nthe first N chars of the username + YYMMDD\n\nso for example:\nmichaeln070612\n\nor with space:\nmichaeln 070612\n\n\n[...]\n> > * on the history page there are \"blob\", \"commitdiff\" and \"diff to current\"\n> >   the obvious missing one is \"diff to previous\" which would be the diff to\n> >   the previous blob of this file\n> \n> Isn't that commitdiff, or commitdiff on that page does not limit\n> the diff to the blob?\n\ncommitdiff doesnt limit it to the blob ...\n\n[...]\n-- \nMichael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB\n\nObserve your enemies, for they first find out your faults. -- Antisthenes\n"},{"id":"41992","messageId":"f25mic$1b1$2@sea.gmane.org","threadId":"8119","inReplyTo":"1f3701c794eb$5ff781b0$0200a8c0@AMD2500","subject":"Re: suggestions for gitweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-13T00:41:10Z","receivedAt":"2007-05-13T00:41:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Gray wrote:\n\n>>> * the history/log pages could contain some statistics for the commits \n>>>   like the number of files changed and lines added/removed\n>>\n>> Probably.\n>>\n>> The three last items should be relatively easy, if somebody is\n>> interested.  Pasky, Jakub, what do you think?\n> \n> I would like to see lines of code and file sizes too.\n\nDiff statistics for difftree / whatchanged, or diff shortstat is a bit\ncostly, as it needs to generate and examine diff, and not only compare\ntrees. Besides --numstat doesn't support renames well now, but that\nmight not be an obstacle.\n\nLines of code and file sizes: file size needs additional invocation\nper each file for gitweb; it would be easier for cgit. Costly! Counting\nLOC is even more costly: take note that 1.) gitweb operates directly\non repository / object database, and does not use working area, \n2.) git is snapshot based and not changeset based.\n\nOf course like in the case of other costly features this migh be enabled\nat will using %feature hash...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"41994","messageId":"7vabw9v906.fsf@assigned-by-dhcp.cox.net","threadId":"8119","inReplyTo":"f25mic$1b1$2@sea.gmane.org","subject":"Re: suggestions for gitweb","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-13T00:54:01Z","receivedAt":"2007-05-13T00:54:01Z","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> Lines of code and file sizes: file size needs additional invocation\n> per each file for gitweb; it would be easier for cgit. Costly! Counting\n> LOC is even more costly: take note that 1.) gitweb operates directly\n> on repository / object database, and does not use working area, \n> 2.) git is snapshot based and not changeset based.\n\nWe earlier discussed to make --numstat to allow us add this kind\nof information for easier script consumption.\n\nPerhaps instead of modifying --numstat, we may be better off to\nadd another format that can be more easily extended to support\nother things, like we do for the --porcelain format out of\ngit-blame?  It does not have to be one line per record, like the\nway --numstat was done, which was primarily in order to make it\na compact, human readable format.\n"},{"id":"42068","messageId":"200705131318.39723.jnareb@gmail.com","threadId":"8119","inReplyTo":"20070513000151.GT14859@MichaelsNB","subject":"Re: suggestions for gitweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-13T11:18:39Z","receivedAt":"2007-05-13T11:18:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 13 May 2007, Michael Niedermayer wrote:\n> On Sat, May 12, 2007 at 03:39:25PM -0700, Junio C Hamano wrote:\n>> Michael Niedermayer <michaelni@gmx.at> writes:\n>> \n>>> * gitweb uses many terms which are new to a non git user, \n>>>   [...] so i belive  \n>>>   a small help text linked to from all pages which contains a short\n>>>   definition of all the git(web) specific terms would be very helpfull\n>>>   something like\n>>>     blob        - file      at a specific revision/date\n>>>     tree        - directory at a specific revision/date\n>>>     (short) log - project wide commit log\n>>>     history     - short log equivalent for a file or directory\n>> \n>> Coming fron non-CVS camp, I think changing this to non-git terms\n>> is very harmful than educating users who are migrating from\n>> other systems.\n> \n> You must have misunderstand me :(\n> I want to educate them, but I cannot as I am not speaking about ffmpeg\n> developers/contributors but rather random people who are curious and \n> want to take a look at the ffmpeg source\n> \n> For them a simple help link similar to \"ViewVC Help\" which ViewVC has\n> on the bottom right of its pages would be great IMHO\n> also the text above is a pure random suggestion by a svn user and was\n> not intended to redefine any git terms\n\nBack in the times where there was no git homepage, the git logo at\ntop right corner of gitweb page was link to git documentation\n  http://www.kernel.org/pub/software/scm/git/docs/\n(with the title of \"git documentation\"), or to be more exact to HTML\nversion of git(7) man page. This page has link to git glossary, where\nyou can find explanation of this terms. Now it is link to git homepage;\nI'm not sure where / if there is here link to git glossary.\n\nIt is very easy to change URL where git logo points to; either via\nsetting appropriate variables when running make to get gitweb.cgi out\nof gitweb.perl, or via configuration file for gitweb. You can point\ngit logo to lead to your documentation of gitweb terms.\n\nBut gitweb was primarly meant for developers which works which git,\nand have knowledge of git terms (and gitweb terms, as gitweb uses them).\n\nAdding some gitweb-help.html page, linked somewhere from within gitweb\npages (I think it shouldn't be embedded in gitweb, like help for search\noptions is), certainly is possible. And perhaps we should do that, now\nthat gitweb is more widely deployed, and used by \"accidental\" users\n(developers) with no knowledge of git, and perhaps even without\nknowledge of SCM [terms].\n\nBy the way, I think only \"blob\" and perhaps \"tree\" terms really needs\nexplanation...\n\n\nSidenote: we used to have some links to 'blob_plain' action, which\nreturns exact contents of file at given revision to the browser\n(trying to set appropriate mime type), named \"plain\" and some named\n\"raw\". This ambiguity was resolved in favor of \"raw\". Is it better?\nI'm not sure...\n\n> [...]\n>>> * on the history page there are \"blob\", \"commitdiff\" and \"diff to current\"\n>>>   the obvious missing one is \"diff to previous\" which would be the diff to\n>>>   the previous blob of this file\n>> \n>> Isn't that commitdiff, or commitdiff on that page does not limit\n>> the diff to the blob?\n> \n> commitdiff doesn't limit it to the blob ...\n\nIt should be fairly easy to add \"diff to prev\" link, but is it really\nneeded? It would be yet another link. Diff to previous version of blob\nis contained in \"commitdiff\" and is easy to find and go to... well,\nunless you are used to make large commits...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"42065","messageId":"200705131350.04916.jnareb@gmail.com","threadId":"8119","inReplyTo":"7vabw9v906.fsf@assigned-by-dhcp.cox.net","subject":"Re: suggestions for gitweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-13T11:50:04Z","receivedAt":"2007-05-13T11:50:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n>> Lines of code and file sizes: file size needs additional invocation\n>> per each file for gitweb; it would be easier for cgit. Costly!\n>> Counting LOC is even more costly: take note that 1.) gitweb operates\n>> directly on repository / object database, and does not use working\n>> area, 2.) git is snapshot based and not changeset based.\n> \n> We earlier discussed to make --numstat to allow us add this kind\n> of information for easier script consumption.\n> \n> Perhaps instead of modifying --numstat, we may be better off to\n> add another format that can be more easily extended to support\n> other things, like we do for the --porcelain format out of\n> git-blame?  It does not have to be one line per record, like the\n> way --numstat was done, which was primarily in order to make it\n> a compact, human readable format.\n\nEven if we extend --numstat or add yet another diff format meant for\nporcelain[*1*], and optionally add similar extension to git-ls-tree\n(as I think object size and LOC of file should be placed there), and\nthe cost of additional fork and exec is not an issue, such extra \ninformation be still costly in terms of performance: CPU and I/O.\n\nCurrently for difftree (whatchanged-like) we need only to compare\ntrees. For lines added / lines removed statistics we need to _generate_ \ndiff.\n\nFor file size (object size) we need at least find the object in question \nand read it's header; for lines of code we need to get blob contents\n(find object, uncompress, optionally undeltify) and count the lines.\n\nIts not insurmountable: we can use %feature for that, like in the case\nof other CPU-intensive features like 'blame' or 'pickaxe', or \nhigh-bandwidth features like 'snapshot'.\n\n\nFootnotes:\n----------\n[*1*] What we should name it? --numstat-extended, --machinestat,\n--porcelain, --allstat, <insert your own idea here>?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"42025","messageId":"8c5c35580705130952r7c0e353dr9cf20aed61bdd463@mail.gmail.com","threadId":"8119","inReplyTo":"f25mic$1b1$2@sea.gmane.org","subject":"Re: suggestions for gitweb","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-05-13T16:52:16Z","receivedAt":"2007-05-13T16:52:16Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 5/13/07, Jakub Narebski <jnareb@gmail.com> wrote:\n> Aaron Gray wrote:\n>\n> >>> * the history/log pages could contain some statistics for the commits\n> >>>   like the number of files changed and lines added/removed\n> >>\n> >> Probably.\n> >>\n> >> The three last items should be relatively easy, if somebody is\n> >> interested.  Pasky, Jakub, what do you think?\n> >\n> > I would like to see lines of code and file sizes too.\n>\n> Diff statistics for difftree / whatchanged, or diff shortstat is a bit\n> costly, as it needs to generate and examine diff, and not only compare\n> trees. Besides --numstat doesn't support renames well now, but that\n> might not be an obstacle.\n>\n> Lines of code and file sizes: file size needs additional invocation\n> per each file for gitweb; it would be easier for cgit. Costly! Counting\n> LOC is even more costly\n\nI've implemented number of files/lines changed in cgit's log view and\npushed it to http://hjemli.net/git/\n\nIt does consume some cpu (especially on the linux-2.6 repo), but it's\nnot terribly bad (and the caching helps out). But I felt like changing\nthe number of commits per page to 50, so I added a knob for this in\nthe config file while at it.\n\nI'll try to get a proper diffstat on the commit page + file history\nvia tree view next (filesize has always been part of cgits tree view\nbtw).\n\n--\nlarsh\n"},{"id":"42078","messageId":"7vveewp7tz.fsf@assigned-by-dhcp.cox.net","threadId":"8119","inReplyTo":"200705131318.39723.jnareb@gmail.com","subject":"Re: suggestions for gitweb","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-14T00:28:08Z","receivedAt":"2007-05-14T00:28:08Z","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> Adding some gitweb-help.html page, linked somewhere from within gitweb\n> pages (I think it shouldn't be embedded in gitweb, like help for search\n> options is), certainly is possible. And perhaps we should do that, now\n> that gitweb is more widely deployed, and used by \"accidental\" users\n> (developers) with no knowledge of git, and perhaps even without\n> knowledge of SCM [terms].\n\nYeah, that is definitely an improvement.\n\n> It should be fairly easy to add \"diff to prev\" link, but is it really\n> needed? It would be yet another link. Diff to previous version of blob\n> is contained in \"commitdiff\" and is easy to find and go to... well,\n> unless you are used to make large commits...\n\nIt would not be \"yet another\".  It feels kind of odd to get the\nwhole commitdiff from that page to begin with, when the user\nalready expressed that his attention is focused on that\nparticular path --- that is why he is in the History page to\nbegin with.\n"},{"id":"42087","messageId":"20070514010831.GH4489@pasky.or.cz","threadId":"8119","inReplyTo":"20070513000151.GT14859@MichaelsNB","subject":"Re: suggestions for gitweb","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-14T01:08:31Z","receivedAt":"2007-05-14T01:08:31Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"  Hi,\n\nOn Sun, May 13, 2007 at 02:01:52AM CEST, Michael Niedermayer wrote:\n> On Sat, May 12, 2007 at 03:39:25PM -0700, Junio C Hamano wrote:\n> > Michael Niedermayer <michaelni@gmx.at> writes:\n> > \n> > > * gitweb uses many terms which are new to a non git user, and while\n> > >   devlopers who work on ffmpeg will very likely very quickly have\n> > >   figured out the meaning of all of them. i think simple users who just\n> > >   want to browse the ffmpeg code will have their problems, so i belive \n> > >   a small help text linked to from all pages which contains a short\n> > >   definition of all the git(web) specific terms would be very helpfull\n> > >   something like\n> > >     blob        - file      at a specific revission/date\n> > >     tree        - directory at a specific revission/date\n> > >     (short) log - project wide commit log\n> > >     history     - short log equivalent for a file or directory\n> > \n> > Coming fron non-CVS camp, I think changing this to non-git terms\n> > is very harmful than educating users who are migrating from\n> > other systems.\n> \n> you must missunderstand me :(\n> i want to educate them, but i cannot as iam not speaking about ffmpeg\n> developers/contributors but rather random people who are curious and \n> want to take a look at the ffmpeg source\n> \n> for them a simple help link similar to \"ViewVC Help\" which viewvc has\n> on the bottom right of its pages would be great IMHO\n> also the text above is a pure random suggestion by a svn user and was\n> not intended to redefine any git terms\n\n  I seriously doubt the usefulness of this. Meaning of all the links except\nmaybe blob seems immediately obvious for me, even if I try to imagine\nthat I know nothing about Git; maybe I'm wrong here, I might try to do\nan experiment. :-)\n\n  But, even if that's the case, when a new user meets gitweb and looks\nat the 'history' link, what do you think she will do? Start hunting the\npage for some link to a glossary? I yet have to see a user like that :-)\n- I will bet that she just clicks at the link and figures out what it is\nabout based on what happenned.\n\n> > > * The blame page shows the SHA1 for each hunk and IMHO thats the last thing\n> > >   i would want to see first, id be much more interrested in by whom and\n> > >   when a given change was done, iam wondering in which case the SHA1 would\n> > >   be usefull? copy-paste onto your command line git tools but then why\n> > >   use gitweb at all, 'git blame' would make more sense IMHO and a simple\n> > >   click would reveal the sha1 with more info anyway ...\n> > \n> > They serve no purpose other than showing something to click on,\n> > and allow you to hover over (some people argued in the past\n> > that they recognize certain commit object names, but honestly I\n> > would not believe them).  However, I do not think there are much\n> > better alternatives.  Try coming up with a different \"label\"\n> > string that is of uniform length across commits, and does not\n> > chew up too much screen real estate.\n> \n> trivial\n> the first N chars of the username + YYMMDD\n> \n> so for example:\n> michaeln070612\n> \n> or with space:\n> michaeln 070612\n\nThis idea occurred to me, but so if a file is born from 20 commits in a\nsingle day, you have no distinction between them. And if you throw time\nin the mix too, it already becomes way too long; I'd argue that even\nusername-date already feels too long.\n\n> [...]\n> > > * on the history page there are \"blob\", \"commitdiff\" and \"diff to current\"\n> > >   the obvious missing one is \"diff to previous\" which would be the diff to\n> > >   the previous blob of this file\n> > \n> > Isn't that commitdiff, or commitdiff on that page does not limit\n> > the diff to the blob?\n> \n> commitdiff doesnt limit it to the blob ...\n\nI don't know if it's better to limit commitdiff or not; a compromise\napproach would be not to limit it but to jump to the fragment concerning\nthe given blob.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"42091","messageId":"20070514020001.GX14859@MichaelsNB","threadId":"8119","inReplyTo":"20070514010831.GH4489@pasky.or.cz","subject":"Re: suggestions for gitweb","fromName":"Michael Niedermayer","fromEmail":"michaelni@gmx.at","sentAt":"2007-05-14T02:00:02Z","receivedAt":"2007-05-14T02:00:02Z","isPatch":false,"sender":{"key":"michaelni@gmx.at","avatar":null},"body":"Hi\n\nOn Mon, May 14, 2007 at 03:08:31AM +0200, Petr Baudis wrote:\n>   Hi,\n> \n> On Sun, May 13, 2007 at 02:01:52AM CEST, Michael Niedermayer wrote:\n> > On Sat, May 12, 2007 at 03:39:25PM -0700, Junio C Hamano wrote:\n> > > Michael Niedermayer <michaelni@gmx.at> writes:\n> > > \n> > > > * gitweb uses many terms which are new to a non git user, and while\n> > > >   devlopers who work on ffmpeg will very likely very quickly have\n> > > >   figured out the meaning of all of them. i think simple users who just\n> > > >   want to browse the ffmpeg code will have their problems, so i belive \n> > > >   a small help text linked to from all pages which contains a short\n> > > >   definition of all the git(web) specific terms would be very helpfull\n> > > >   something like\n> > > >     blob        - file      at a specific revission/date\n> > > >     tree        - directory at a specific revission/date\n> > > >     (short) log - project wide commit log\n> > > >     history     - short log equivalent for a file or directory\n> > > \n> > > Coming fron non-CVS camp, I think changing this to non-git terms\n> > > is very harmful than educating users who are migrating from\n> > > other systems.\n> > \n> > you must missunderstand me :(\n> > i want to educate them, but i cannot as iam not speaking about ffmpeg\n> > developers/contributors but rather random people who are curious and \n> > want to take a look at the ffmpeg source\n> > \n> > for them a simple help link similar to \"ViewVC Help\" which viewvc has\n> > on the bottom right of its pages would be great IMHO\n> > also the text above is a pure random suggestion by a svn user and was\n> > not intended to redefine any git terms\n> \n>   I seriously doubt the usefulness of this. Meaning of all the links except\n> maybe blob seems immediately obvious for me, even if I try to imagine\n> that I know nothing about Git; maybe I'm wrong here, I might try to do\n> an experiment. :-)\n> \n>   But, even if that's the case, when a new user meets gitweb and looks\n> at the 'history' link, what do you think she will do? Start hunting the\n> page for some link to a glossary? I yet have to see a user like that :-)\n> - I will bet that she just clicks at the link and figures out what it is\n> about based on what happenned.\n\ni agree with you that she will click on 'history' and figure out what it is\nbut if she wants to see the contents of one of the files then i think\nshe will be confused and not know where to click, and a 'help' link which\nwould lead to a page which explains what 'blob' is at the top of the page\nwould solve that with less frustration than random clicking around\n(renaming blob to file_content would work too but i guess i would be\n lynched for mere suggesting ...)\n\nthis of course is not really a problem for ffmpeg, we could easily change\n\"our\" gitweb to contain a help link\n\n[...]\n-- \nMichael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB\n\nThe misfortune of the wise is better than the prosperity of the fool.\n-- Epicurus\n"},{"id":"42092","messageId":"20070514023609.GI18276@pasky.or.cz","threadId":"8119","inReplyTo":"20070514020001.GX14859@MichaelsNB","subject":"Re: suggestions for gitweb","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-14T02:36:09Z","receivedAt":"2007-05-14T02:36:09Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, May 14, 2007 at 04:00:02AM CEST, Michael Niedermayer wrote:\n> i agree with you that she will click on 'history' and figure out what it is\n> but if she wants to see the contents of one of the files then i think\n> she will be confused and not know where to click,\n\nI think she will just click on the filename - straightforward enough...?\n\n> and a 'help' link which\n> would lead to a page which explains what 'blob' is at the top of the page\n> would solve that with less frustration than random clicking around\n> (renaming blob to file_content would work too but i guess i would be\n>  lynched for mere suggesting ...)\n\n:-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"42098","messageId":"200705140931.32513.jnareb@gmail.com","threadId":"8119","inReplyTo":"8c5c35580705130952r7c0e353dr9cf20aed61bdd463@mail.gmail.com","subject":"Suggestions for cgit (was: Re: suggestions for gitweb)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-14T07:31:32Z","receivedAt":"2007-05-14T07:31:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 13 May 2007, Lars Hjemli <hjemli@gmail.com> wrote:\n\n> I've implemented number of files/lines changed in cgit's log view and\n> pushed it to http://hjemli.net/git/\n> \n> It does consume some cpu (especially on the linux-2.6 repo), but it's\n> not terribly bad (and the caching helps out). But I felt like changing\n> the number of commits per page to 50, so I added a knob for this in\n> the config file while at it.\n> \n> I'll try to get a proper diffstat on the commit page + file history\n> via tree view next (filesize has always been part of cgits tree view\n> btw).\n\nWhat I lack in cgit is using git diff and showing extended diff headers\n(and the ugly tight box around diff doesn't help either), and gitweb's\n'commitdiff' view / git's git-show / git's git-format-patch.\n\nI don't think displaying filesize slows cgit much (you need to find and\nread object header for that, as this information is not present in a\ntree object...\n\nBy the way, what do you think about http://git.or.cz/gitwiki/Gitweb \npage?\n-- \nJakub Narebski\nPoland\n"},{"id":"42102","messageId":"8c5c35580705140150i85ef898h6ac0475ab12f8a03@mail.gmail.com","threadId":"8119","inReplyTo":"200705140931.32513.jnareb@gmail.com","subject":"Re: Suggestions for cgit (was: Re: suggestions for gitweb)","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-05-14T08:50:04Z","receivedAt":"2007-05-14T08:50:04Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 5/14/07, Jakub Narebski <jnareb@gmail.com> wrote:\n> On Sun, 13 May 2007, Lars Hjemli <hjemli@gmail.com> wrote:\n>\n> > I've implemented number of files/lines changed in cgit's log view and\n> > pushed it to http://hjemli.net/git/\n> >\n> > It does consume some cpu (especially on the linux-2.6 repo), but it's\n> > not terribly bad (and the caching helps out). But I felt like changing\n> > the number of commits per page to 50, so I added a knob for this in\n> > the config file while at it.\n> >\n> > I'll try to get a proper diffstat on the commit page + file history\n> > via tree view next (filesize has always been part of cgits tree view\n> > btw).\n>\n> What I lack in cgit is using git diff and showing extended diff headers\n> (and the ugly tight box around diff doesn't help either), and gitweb's\n> 'commitdiff' view / git's git-show / git's git-format-patch.\n\nYes, this has been lacking. Last night I pushed initial support for\n'commitdiff', but it doesn't show git's extended diff headers, nor is\nthere any plain/patch view (but the ugly tiny box is still there, I'm\nlousy at web design :)\n\nThat said, extended headers/patch view should be trivial to support so\nI'll look into it.\n\n\n> I don't think displaying filesize slows cgit much (you need to find and\n> read object header for that, as this information is not present in a\n> tree object...\n\nTrue, I do\n\n  type = sha1_object_info(sha1, &size)\n\nper entry in tree view to get the size. It's fast.\n\n\n> By the way, what do you think about http://git.or.cz/gitwiki/Gitweb\n> page?\n\nNice, I hadn't noticed this page, maybe cgit should get one too? Well,\nit probably should get some users first (are there anyone besides\nmyself?)\n\n-- \nlarsh\n"},{"id":"42103","messageId":"20070514085314.GY14859@MichaelsNB","threadId":"8119","inReplyTo":"20070514023609.GI18276@pasky.or.cz","subject":"Re: suggestions for gitweb","fromName":"Michael Niedermayer","fromEmail":"michaelni@gmx.at","sentAt":"2007-05-14T08:53:15Z","receivedAt":"2007-05-14T08:53:15Z","isPatch":false,"sender":{"key":"michaelni@gmx.at","avatar":null},"body":"Hi\n\nOn Mon, May 14, 2007 at 04:36:09AM +0200, Petr Baudis wrote:\n> On Mon, May 14, 2007 at 04:00:02AM CEST, Michael Niedermayer wrote:\n> > i agree with you that she will click on 'history' and figure out what it is\n> > but if she wants to see the contents of one of the files then i think\n> > she will be confused and not know where to click,\n> \n> I think she will just click on the filename - straightforward enough...?\n\nyes and no :)\ni see 2 possible problems with this\nfirst if she starts from the summary page (which is from where she would\nstart from if she clicked on 'ffmpeg') then she would see the recent \nhistory but no directory/file names, she would have to click on 'tree' \nhere\n\nthe second possible problem i see is that while directory names are\ndisplayed in iceweasel in underlined blue like links, filenames are\nnot, so she might not realize that she can click on them\n\nanother thing i just realized is that the blob/tree links on the tree\npage seems redundant as the directory/file names already link to these\npages, iam just mentioning that as some people in this thread seemed to\nlike minimizing the number of links and the length of varous displayed\nitems\n\nalso file size and last modified dates would be interresting on the tree\npage\nviewvc displays on its equivalent page, time since last change\nsvn revission of the last change, the author/commiter of the last change\nand the corresponding abbreviated log entry\n\n[...]\n-- \nMichael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB\n\nit is not once nor twice but times without number that the same ideas make\ntheir appearance in the world. -- Aristotle\n"},{"id":"42105","messageId":"20070514095857.GI4489@pasky.or.cz","threadId":"8119","inReplyTo":"20070514085314.GY14859@MichaelsNB","subject":"Re: suggestions for gitweb","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-14T09:58:57Z","receivedAt":"2007-05-14T09:58:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"  Hi,\n\nOn Mon, May 14, 2007 at 10:53:15AM CEST, Michael Niedermayer wrote:\n> On Mon, May 14, 2007 at 04:36:09AM +0200, Petr Baudis wrote:\n> > On Mon, May 14, 2007 at 04:00:02AM CEST, Michael Niedermayer wrote:\n> > > i agree with you that she will click on 'history' and figure out what it is\n> > > but if she wants to see the contents of one of the files then i think\n> > > she will be confused and not know where to click,\n> > \n> > I think she will just click on the filename - straightforward enough...?\n> \n> yes and no :)\n> i see 2 possible problems with this\n> first if she starts from the summary page (which is from where she would\n> start from if she clicked on 'ffmpeg') then she would see the recent \n> history but no directory/file names, she would have to click on 'tree' \n> here\n\n  well, I guess our opinions on how hard it is to guess it through just\ndiffer... :-)\n\n> also file size and last modified dates would be interresting on the tree\n> page\n> viewvc displays on its equivalent page, time since last change\n> svn revission of the last change, the author/commiter of the last change\n> and the corresponding abbreviated log entry\n\n  I guess this is much easier to retrieve in svn than in git - you\nactually have to walk all the history to figure out this information as\nthere's no global per-file info; so this is very troublesome\nperformance-wise. I think there were some patches on the mailinglist\nthat dit this, though I'm not sure. Might be reasonable to cache this\n(and git history properties make it possible to nicely make a very\neasily reusable cache for this information).\n\n  About file sizes, that also has some extra performance hit, but in\nthis case I suspect that it would be totally negligible (if implemented\nat the plumbing level) - and I admit that I would like to see file sizes\ntoo, they can help orientation in a foreign source tree a lot.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"42144","messageId":"200705141849.36457.jnareb@gmail.com","threadId":"8119","inReplyTo":"20070514095857.GI4489@pasky.or.cz","subject":"Re: suggestions for gitweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-14T16:49:35Z","receivedAt":"2007-05-14T16:49:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 14 May 2007, Petr Baudis <pasky@suse.cz> wrote:\n> On Mon, May 14, 2007 at 10:53:15AM CEST, Michael Niedermayer wrote:\n\n>> also file size and last modified dates would be interresting on the tree\n>> page\n>> viewvc displays on its equivalent page, time since last change\n>> svn revission of the last change, the author/commiter of the last change\n>> and the corresponding abbreviated log entry\n> \n>   I guess this is much easier to retrieve in svn than in git - you\n> actually have to walk all the history to figure out this information as\n> there's no global per-file info; so this is very troublesome\n> performance-wise. I think there were some patches on the mailinglist\n> that dit this, though I'm not sure. Might be reasonable to cache this\n> (and git history properties make it possible to nicely make a very\n> easily reusable cache for this information).\n\nI have sent some implementations of tree_blame, without any core\nsupport, directly in Perl (in gitweb), just like early versions of\ngit-annotate. It did suck performance-wise quite a bit. You can find\nit in 'gitweb/tree_blame' branch in my git repository at repo.or.cz\n\n  http://repo.or.cz/w/git/jnareb-git.git?a=shortlog;h=gitweb/tree_blame\n\nI think it would be nice to have --blame option to git-ls-tree \n(optionally copuled with --porcelain and perhaps --incremental, like\nin git-blame), which would return blame information for tree entries.\nIt means that for each tree entry return commit closest to given commit\n(or furthest from a given commit) which has changed entry to current\nversion. It should be much easier and faster than to do \"blob\"-blame.\n\nThe --porcelain would also return 'last changed' info, like committer\ninfo for a commit-which-changed.\n\nBut is this info actually interesting, or is it there in ViewVC because\nit is easy to get this info in CVS and Subversion? The \"last changed\"\ninfo for tree entries encourages to think of a history as a collection\nof per file histories... while git is all about whole project history.\nNote that history of two files is *more* than concatenation of\nhistories of those individual files. See entries on GitFaq wiki page:\n \n>   About file sizes, that also has some extra performance hit, but in\n> this case I suspect that it would be totally negligible (if implemented\n> at the plumbing level) - and I admit that I would like to see file sizes\n> too, they can help orientation in a foreign source tree a lot.\n\nIt should be very easy to add --long / --sizes option to git-ls-tree\nwhich would return file sizes, perhaps after mode info.\n\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n"},{"id":"42151","messageId":"20070514173714.GA14859@MichaelsNB","threadId":"8119","inReplyTo":"200705141849.36457.jnareb@gmail.com","subject":"Re: suggestions for gitweb","fromName":"Michael Niedermayer","fromEmail":"michaelni@gmx.at","sentAt":"2007-05-14T17:37:15Z","receivedAt":"2007-05-14T17:37:15Z","isPatch":false,"sender":{"key":"michaelni@gmx.at","avatar":null},"body":"Hi\n\nOn Mon, May 14, 2007 at 06:49:35PM +0200, Jakub Narebski wrote:\n[...]\n> I think it would be nice to have --blame option to git-ls-tree \n> (optionally copuled with --porcelain and perhaps --incremental, like\n> in git-blame), which would return blame information for tree entries.\n> It means that for each tree entry return commit closest to given commit\n> (or furthest from a given commit) which has changed entry to current\n> version. It should be much easier and faster than to do \"blob\"-blame.\n> \n> The --porcelain would also return 'last changed' info, like committer\n> info for a commit-which-changed.\n> \n> But is this info actually interesting, or is it there in ViewVC because\n> it is easy to get this info in CVS and Subversion? The \"last changed\"\n> info for tree entries encourages to think of a history as a collection\n> of per file histories... while git is all about whole project history.\n> Note that history of two files is *more* than concatenation of\n> histories of those individual files. See entries on GitFaq wiki page:\n\nwell, i do think that the age can be interesting, consider the 2\nhypothetical cases:\n'release_notes.txt 5 years ago' while all other files have been recently\nchanged\nclearly says: noone cares about this file or there was no release in \nthe last 5 years\n\nalso for example\n'vo_x11.c    2 days ago  michael     update all vos to use correct foobar'\n'vo_mga.c    8 weeks ago diego       spelling fixes'\nwould immedeatly hint that ive forgotten vo_mga.c ...\n\n[...]\n-- \nMichael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB\n\nLet us carefully observe those good qualities wherein our enemies excel us\nand endeavor to excel them, by avoiding what is faulty, and imitating what\nis excellent in them. -- Plutarch\n"},{"id":"42219","messageId":"8c5c35580705150557k694abfb6rb8f87763dfd26c81@mail.gmail.com","threadId":"8119","inReplyTo":"8c5c35580705140150i85ef898h6ac0475ab12f8a03@mail.gmail.com","subject":"Re: Suggestions for cgit (was: Re: suggestions for gitweb)","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-05-15T12:57:16Z","receivedAt":"2007-05-15T12:57:16Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 5/14/07, Lars Hjemli <hjemli@gmail.com> wrote:\n> On 5/14/07, Jakub Narebski <jnareb@gmail.com> wrote:\n> > On Sun, 13 May 2007, Lars Hjemli <hjemli@gmail.com> wrote:\n> >\n> > > I've implemented number of files/lines changed in cgit's log view and\n> > > pushed it to http://hjemli.net/git/\n> > >\n> > > It does consume some cpu (especially on the linux-2.6 repo), but it's\n> > > not terribly bad (and the caching helps out). But I felt like changing\n> > > the number of commits per page to 50, so I added a knob for this in\n> > > the config file while at it.\n> > >\n> > > I'll try to get a proper diffstat on the commit page + file history\n> > > via tree view next (filesize has always been part of cgits tree view\n> > > btw).\n> >\n> > What I lack in cgit is using git diff and showing extended diff headers\n> > (and the ugly tight box around diff doesn't help either), and gitweb's\n> > 'commitdiff' view / git's git-show / git's git-format-patch.\n>\n> Yes, this has been lacking. Last night I pushed initial support for\n> 'commitdiff', but it doesn't show git's extended diff headers, nor is\n> there any plain/patch view (but the ugly tiny box is still there, I'm\n> lousy at web design :)\n>\n> That said, extended headers/patch view should be trivial to support so\n> I'll look into it.\n\nOk, the ugly box is gone and 'commit-diff' now looks more like 'git\nshow'. Thanks for the suggestion.\n\n--\nlarsh\n"},{"id":"42227","messageId":"20070515154613.GB3653@efreet.light.src","threadId":"8119","inReplyTo":"20070514020001.GX14859@MichaelsNB","subject":"Re: suggestions for gitweb","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-05-15T15:46:13Z","receivedAt":"2007-05-15T15:46:13Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"Hello,\n\nOn Mon, May 14, 2007 at 04:00:02 +0200, Michael Niedermayer wrote:\n> On Mon, May 14, 2007 at 03:08:31AM +0200, Petr Baudis wrote:\n> >   But, even if that's the case, when a new user meets gitweb and looks\n> > at the 'history' link, what do you think she will do? Start hunting the\n> > page for some link to a glossary? I yet have to see a user like that :-)\n> > - I will bet that she just clicks at the link and figures out what it is\n> > about based on what happenned.\n> \n> i agree with you that she will click on 'history' and figure out what it is\n> but if she wants to see the contents of one of the files then i think\n\nWell, before clicking it, she will move the mouse pointer over it. And either\nlook for tooltip -- which sadly won't come up -- or read the url -- with\nsadly isn't much help.\n\n> she will be confused and not know where to click, and a 'help' link which\n> would lead to a page which explains what 'blob' is at the top of the page\n> would solve that with less frustration than random clicking around\n\nIMHO providing tooltips would probably solve it with even less frustration.\nIf the user comes to the page, she will probably quickly notice, that the\nlinks have tooltips. And than going over all the links with the pointer and\nreading the tooltips is a lot easier and faster than switching to a help\npage. Besides people don't want to admit, even to themselves, they don't\nunderstand something to a point they should read the docs, so they won't read\nit. But anybody will read the tooltips -- they don't look like docs.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"}]}