{"thread":{"id":"2244","subject":"[PATCH gitweb] Visually indicating patch size with horizontal bars","startedAt":"2005-10-27T20:39:45Z","lastAt":"2005-12-05T01:03:35Z","messageCount":27,"participants":["Chris Shoemaker","Junio C Hamano","Linus Torvalds","Martin Langhoff","H. Peter Anvin","Kay Sievers","Andreas Ericsson","Josef Weidendorfer","Petr Baudis","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"10718","messageId":"20051027203945.GC1622@pe.Belkin","threadId":"2244","inReplyTo":null,"subject":"[PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2005-10-27T20:39:45Z","receivedAt":"2005-10-27T20:39:45Z","isPatch":true,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"\nI really like gitweb (thanks Kay!), but I thought it would be nice to\nhave a visual indication of patch size. I found this helpful when\nscanning though the shortlogs.\n\nTo see what it looks like with the gitweb for gitweb (meta-gitweb?)\ngoto:\n\nhttp://www.codesifter.com/cgi-bin/gitweb.cgi?p=gitweb.git;a=shortlog\n\nI rather like the look of what I've hacked up (the enclosed patch),\nbut it should be considered as just a prototype: it only affects the\nshortlog, it's horribly inefficient, and I don't really do perl. :)\n\nIf anyone thinks this is a good feature, then please tell me an\nefficient way to get some heuristic of the patch size.\n\nRight now, I'm using: \n\nGIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l\n\nwhich is pretty slow. Any suggestions?\n\n-chris\n\n\nSubject: [PATCH] initial hack at horizontal bars indicating patch size\n\n---\n\n gitweb.cgi | 38 +++++++++++++++++++++++++++++++++++++-\n 1 files changed, 37 insertions(+), 1 deletions(-)\n\nc8d45f9a3cfdd7080a57e0de315f3ab9475f60bf\ndiff --git a/gitweb.cgi b/gitweb.cgi\n--- a/gitweb.cgi\n+++ b/gitweb.cgi\n@@ -53,6 +53,9 @@ if (defined $action) {\n \t} elsif ($action eq \"opml\") {\n \t\tgit_opml();\n \t\texit;\n+\t} elsif ($action eq \"bar.png\") {\n+\t git_bar_png();\n+\t exit;\n \t}\n }\n \n@@ -358,6 +361,16 @@ sub git_get_type {\n \treturn $type;\n }\n \n+sub git_get_commit_size {\n+\tmy $hash = shift;\n+\n+\topen my $fd, \"-|\", \"GIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l\" or return;\n+\tmy $size = <$fd>;\n+\tclose $fd or return;\n+\tchomp $size;\n+\treturn $size;\n+}\n+\n sub git_read_hash {\n \tmy $path = shift;\n \n@@ -719,6 +732,21 @@ sub git_logo {\n \t\t\"\\x12\\x1c\\x9a\\xfe\\x00\\x00\\x00\\x00\\x49\\x45\\x4e\\x44\\xae\\x42\\x60\\x82\";\n }\n \n+# git_bar_png (cached in browser for one day)\n+sub git_bar_png {\n+\tprint $cgi->header(-type => 'image/png', -expires => '+1d');\n+ # cat bar.png | hexdump -e '\"q\" 16/1 \"w%02x\" \"q . \\n\"' | \n+ # sed 's/w/\\\\x/g' | sed 's/q/\"/g'\n+print \"\\x89\\x50\\x4e\\x47\\x0d\\x0a\\x1a\\x0a\\x00\\x00\\x00\\x0d\\x49\\x48\\x44\\x52\" .\n+\"\\x00\\x00\\x00\\x01\\x00\\x00\\x00\\x0c\\x08\\x02\\x00\\x00\\x00\\x2c\\xe9\\x40\" .\n+\"\\x00\\x00\\x00\\x00\\x3b\\x49\\x44\\x41\\x54\\x08\\x1d\\x01\\x30\\x00\\xcf\\xff\" .\n+\"\\x00\\xba\\xba\\xff\\x02\\xf1\\xf1\\x00\\x02\\xf2\\xf2\\x00\\x02\\xf1\\xf2\\x00\" .\n+\"\\x02\\xf2\\xf1\\x00\\x02\\xf1\\xf1\\x00\\x02\\xf2\\xf1\\x00\\x02\\xf1\\xf1\\x00\" .\n+\"\\x02\\xf1\\xf2\\x00\\x02\\xf1\\xf1\\x00\\x02\\xf2\\xf2\\x00\\x02\\xf2\\xf1\\x00\" .\n+\"\\x45\\x85\\x17\\x49\\x14\\x70\\x67\\xdb\\x00\\x00\\x00\\x00\\x49\\x45\\x4e\\x44\" .\n+\"\\xae\\x42\\x60\\x82\";\n+}\n+\n sub get_file_owner {\n \tmy $path = shift;\n \n@@ -2280,8 +2308,16 @@ sub git_shortlog {\n \t\t \"\" .\n \t\t $cgi->a({-href => \"$my_uri?p=$project;a=commit;h=$commit\"}, \"commit\") .\n \t\t \" | \" . $cgi->a({-href => \"$my_uri?p=$project;a=commitdiff;h=$commit\"}, \"commitdiff\") .\n-\t\t \"\\n\" .\n+\t\t \"\\n\";\n+\t\tmy $scale = 100;\n+\t\tmy $stretch = 32;\n+\t\t# commits of size 1.7*$scale will be $stretch pixels wide \n+\t\tmy $size = int(log((git_get_commit_size($commit)+$scale)/$scale)*$stretch);\n+\t\tprint \"\" .\n+\t\t \"\" .\n+\t\t \"\" .\n \t\t \"\";\n+\n \t}\n \tif ($#revlist >= (100 * ($page+1)-1)) {\n \t\tprint \"\\n\" .\n"},{"id":"10721","messageId":"7vfyqm1uvx.fsf@assigned-by-dhcp.cox.net","threadId":"2244","inReplyTo":"20051027203945.GC1622@pe.Belkin","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-27T22:02:10Z","receivedAt":"2005-10-27T22:02:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Shoemaker writes:\n\n> If anyone thinks this is a good feature, then please tell me an\n> efficient way to get some heuristic of the patch size.\n>\n> Right now, I'm using: \n>\n> GIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l\n>\n> which is pretty slow. Any suggestions?\n\n* do we really want to know the number of lines? sometimes the\n number of pahts that are affected is more useful than number\n of lines when assessing the damage, which can be done with\n 'git-diff-tree --name-only'.\n\n* cache the result -- they never change.\n\nAn interesting question is what to do with merges, but probably\nwe can just ignore it for now.\n"},{"id":"10722","messageId":"20051027234813.GA512@pe.Belkin","threadId":"2244","inReplyTo":"7vfyqm1uvx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2005-10-27T23:48:13Z","receivedAt":"2005-10-27T23:48:13Z","isPatch":true,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Thu, Oct 27, 2005 at 03:02:10PM -0700, Junio C Hamano wrote:\n> Chris Shoemaker writes:\n> \n> > If anyone thinks this is a good feature, then please tell me an\n> > efficient way to get some heuristic of the patch size.\n> >\n> > Right now, I'm using: \n> >\n> > GIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l\n> >\n> > which is pretty slow. Any suggestions?\n> \n> * do we really want to know the number of lines? sometimes the\n> number of pahts that are affected is more useful than number\n> of lines when assessing the damage, which can be done with\n> 'git-diff-tree --name-only'.\n\nThat only shows the top-level names, so when 100s of files changes in\na subdir it looks just like one entry. It's ok when there's no\nsubdirs, but it just doesn't work when 95% of the code is under,\ne.g. src/.\n\n> \n> * cache the result -- they never change.\n\nTrue. Maybe gitk and gitweb can share a cache containing the tree\ndiffs. Or maybe git-core can cache tree diffs?\n\n> \n> An interesting question is what to do with merges, but probably\n> we can just ignore it for now.\n\nIt's trivial to, e.g. use a different image for merges, maybe based on\n# of parents?\n\nBut, in general, is there interest in a visual indicator of commit\nsize and/or type in gitweb?\n\n-chris\n"},{"id":"10723","messageId":"Pine.LNX.4.64.0510271709120.4664@g5.osdl.org","threadId":"2244","inReplyTo":"20051027234813.GA512@pe.Belkin","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-28T00:12:33Z","receivedAt":"2005-10-28T00:12:33Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 27 Oct 2005, Chris Shoemaker wrote:\n> > \n> > * do we really want to know the number of lines? sometimes the\n> > number of pahts that are affected is more useful than number\n> > of lines when assessing the damage, which can be done with\n> > 'git-diff-tree --name-only'.\n> \n> That only shows the top-level names, so when 100s of files changes in\n> a subdir it looks just like one entry. It's ok when there's no\n> subdirs, but it just doesn't work when 95% of the code is under,\n> e.g. src/.\n\nAdd the \"-r\" flag to do the recursive thing, ie\n\n\tgit-diff-tree -r --name-only\n\nshould do the right thing.\n\n> True. Maybe gitk and gitweb can share a cache containing the tree\n> diffs. Or maybe git-core can cache tree diffs?\n\nCreating them is fast enough if there is no IO. Make sure your project is \npacked, and you should be ok.\n\nThe expensive part is the \"-p\" thing to create patches. If you avoid the \npatch creation, you should be ok.\n\n> But, in general, is there interest in a visual indicator of commit\n> size and/or type in gitweb?\n\nI kind of like it, but I'm not sure how useful it is, and maybe it does \nreally want the whole patch size (not just how many files it touches). \nThat's where caching might save your *ss.\n\n\t\tLinus\n"},{"id":"10724","messageId":"20051028005029.GA2654@pe.Belkin","threadId":"2244","inReplyTo":"Pine.LNX.4.64.0510271709120.4664@g5.osdl.org","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2005-10-28T00:50:29Z","receivedAt":"2005-10-28T00:50:29Z","isPatch":true,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Thu, Oct 27, 2005 at 05:12:33PM -0700, Linus Torvalds wrote:\n> Add the \"-r\" flag to do the recursive thing, ie\n> \n> \tgit-diff-tree -r --name-only\n> \n> should do the right thing.\n\nAh, yes, it does. Thanks.\n\n> > True. Maybe gitk and gitweb can share a cache containing the tree\n> > diffs. Or maybe git-core can cache tree diffs?\n> \n> Creating them is fast enough if there is no IO. Make sure your project is \n> packed, and you should be ok.\n> \n> The expensive part is the \"-p\" thing to create patches. If you avoid the \n> patch creation, you should be ok.\n\ngit-diff-tree -r --name-only is pretty quick and it actually does a\nhalfway reasonable job of representing damage-potential.\n\n> > But, in general, is there interest in a visual indicator of commit\n> > size and/or type in gitweb?\n> \n> I kind of like it, but I'm not sure how useful it is, and maybe it does \n> really want the whole patch size (not just how many files it touches). \n\nHard to say. Neither one is going to be perfect, so I'm ok with\nsettling for the cheap one if it's halfway reasonable. I think I'll\nmock up the merge indicator and see if there's any value added there.\n\nSo, what's the best way to detect merges? Maybe see if\n'git-cat-file commit $hash | grep ^parent | wc -l' is greater than 1?\n\n> That's where caching might save your *ss.\n\nOk, but that cache would live inside GIT_DIR an be shared with gitk,\nright?\n\n-chris\n"},{"id":"10725","messageId":"46a038f90510271808n36a75676y9f50109db43b5ab@mail.gmail.com","threadId":"2244","inReplyTo":"20051028005029.GA2654@pe.Belkin","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-28T01:08:13Z","receivedAt":"2005-10-28T01:08:13Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/28/05, Chris Shoemaker wrote:\n> So, what's the best way to detect merges? Maybe see if\n> 'git-cat-file commit $hash | grep ^parent | wc -l' is greater than 1?\n>\n> > That's where caching might save your *ss.\n>\n> Ok, but that cache would live inside GIT_DIR an be shared with gitk,\n> right?\n\ngitweb should have any caches it wants, regardless of gitk, methinks.\n\nI very rarely run gitk and gitweb on the same repo. The repos where I\nrun gitk are all development repos, on my desktop machine or laptop.\ngitweb runs only on the webserver where I publish those...\n\nSo it may be practical to have a common cache format, but unlikely\nthat both programs will use the same cached data in practice...\n\n\nmartin\n"},{"id":"10726","messageId":"43617B47.3070008@zytor.com","threadId":"2244","inReplyTo":"20051028005029.GA2654@pe.Belkin","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-28T01:13:43Z","receivedAt":"2005-10-28T01:13:43Z","isPatch":true,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Chris Shoemaker wrote:\n> \n> Ok, but that cache would live inside GIT_DIR an be shared with gitk,\n> right?\n> \n\nThat would be bad. Don't assume that the person running gitweb (or \ngitk, for that matter) has write permission.\n\n\t-hpa\n"},{"id":"10727","messageId":"46a038f90510271816i26389d5cqe136f515007ca057@mail.gmail.com","threadId":"2244","inReplyTo":"7vfyqm1uvx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-28T01:16:09Z","receivedAt":"2005-10-28T01:16:09Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/28/05, Junio C Hamano wrote:\n> > which is pretty slow. Any suggestions?\n>\n> * do we really want to know the number of lines?\n\nWhat about both? And sugar (rename detection) on top! ;-)\n\nIf you try an find the largest commit (by line count) in the gitweb\nrevision history, you bump into the gitweb.pl -> gitweb.cgi rename.\n\ncheers,\n\n\nmartin\n"},{"id":"10729","messageId":"20051028015642.GA31822@vrfy.org","threadId":"2244","inReplyTo":"20051027203945.GC1622@pe.Belkin","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-10-28T01:56:42Z","receivedAt":"2005-10-28T01:56:42Z","isPatch":true,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Thu, Oct 27, 2005 at 04:39:45PM -0400, Chris Shoemaker wrote:\n> \n> I really like gitweb (thanks Kay!), but I thought it would be nice to\n> have a visual indication of patch size. I found this helpful when\n> scanning though the shortlogs.\n\nThis looks nice, but if the patch size tells you something important,\nyour commit subjects are probably too short or wrong. :)\n\n> To see what it looks like with the gitweb for gitweb (meta-gitweb?)\n> goto:\n> \n> http://www.codesifter.com/cgi-bin/gitweb.cgi?p=gitweb.git;a=shortlog\n> \n> I rather like the look of what I've hacked up (the enclosed patch),\n> but it should be considered as just a prototype: it only affects the\n> shortlog, it's horribly inefficient, and I don't really do perl. :)\n> \n> If anyone thinks this is a good feature, then please tell me an\n> efficient way to get some heuristic of the patch size.\n\nYou may try to use CSS instead of an embedded picture to draw the bar,\njust like the RSS logo in the footer, which is simple CSS rendered in the\nbrowser.\n\nKay\n"},{"id":"10730","messageId":"Pine.LNX.4.64.0510271933140.4664@g5.osdl.org","threadId":"2244","inReplyTo":"46a038f90510271816i26389d5cqe136f515007ca057@mail.gmail.com","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-28T02:38:21Z","receivedAt":"2005-10-28T02:38:21Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 28 Oct 2005, Martin Langhoff wrote:\n>\n> On 10/28/05, Junio C Hamano wrote:\n> > > which is pretty slow. Any suggestions?\n> >\n> > * do we really want to know the number of lines?\n> \n> What about both? And sugar (rename detection) on top! ;-)\n\nWell, if you do full copy detection (and break detection), then \ngit-diff-tree will actually have effectively calculated the size of the \ndiff of each file. It just doesn't print them (well, it does a percentage \nfor the renames/copies).\n\nSo you could make git-diff-tree tell you how big the patch was, without \nactually generating a patch at all. It will be quite a bit more expensive \nthan just a plain \"git-diff-tree -r --name-only\", but if you cache the \nresult is might be quite acceptable.\n\nCaching the result might be as simple as just telling the caching \nweb-server that the result is static and never changes - no need to \ncache things inside of gitweb itself. Just set expiration to \"never\".\n\nAnybody wants to add a new output format to git-diff-tree that outputs how \nbig the changes are in absolute terms (rather than the \"similarity index\", \nwhich is obviously relative to the original size of the file in question)?\n\n\t\tLinus\n"},{"id":"10731","messageId":"20051028023833.GA19939@pe.Belkin","threadId":"2244","inReplyTo":"20051028015642.GA31822@vrfy.org","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2005-10-28T02:38:33Z","receivedAt":"2005-10-28T02:38:33Z","isPatch":true,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Fri, Oct 28, 2005 at 03:56:42AM +0200, Kay Sievers wrote:\n> On Thu, Oct 27, 2005 at 04:39:45PM -0400, Chris Shoemaker wrote:\n> > \n> > I really like gitweb (thanks Kay!), but I thought it would be nice to\n> > have a visual indication of patch size. I found this helpful when\n> > scanning though the shortlogs.\n> \n> This looks nice, but if the patch size tells you something important,\n> your commit subjects are probably too short or wrong. :)\n\nYeah, some people write lousy commit subjects. But me? Nooo,\n/never/. :)\n\n> You may try to use CSS instead of an embedded picture to draw the bar,\n> just like the RSS logo in the footer, which is simple CSS rendered in the\n> browser.\n\nI'll look into that, but the cost wasn't in the image; it was in the\nwidth calculation.\n\nHere's a side-by-side comparison. Open two browser tabs and flip between them:\n\nhttp://www.codesifter.com/cgi-bin/gitweb-difftreeP.cgi?p=git.git;a=shortlog\nhttp://www.codesifter.com/cgi-bin/gitweb-difftreeNames.cgi?p=git.git;a=shortlog\n\nI've used a project you all are familar with, and that has more than\ntwo files. The first page uses 'git-diff-tree -p $hash|wc -l'. The\nsecond page uses 'git-diff-tree -r --name-only|wc -l'. (Oh and I have\na merge indicator now.)\n\nHow do they compare for showing damage-potential? I think they both\ndo a reasonable job. I think the full patch diff is a bit better, but\nit does cost.\n\n-chris\n"},{"id":"10745","messageId":"7vr7a6z4bc.fsf@assigned-by-dhcp.cox.net","threadId":"2244","inReplyTo":"Pine.LNX.4.64.0510271933140.4664@g5.osdl.org","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-28T03:52:07Z","receivedAt":"2005-10-28T03:52:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Well, if you do full copy detection (and break detection), then \n> git-diff-tree will actually have effectively calculated the size of the \n> diff of each file. It just doesn't print them (well, it does a percentage \n> for the renames/copies).\n\nUnbroken in-place edit would never go through diffcore-rename,\nso that is a gross overstatement.\n\nBut we could if we wanted to. I do not know how useful it would\nbe, but if somebody wants to do it, I think the best strategy is\nto do as a separate diffcore backend that comes after\ndiffcore_rename() runs, and do the similarity estimator only on\nfilepairs that rename/copy did not touch.\n"},{"id":"10753","messageId":"4361E155.2020201@op5.se","threadId":"2244","inReplyTo":"43617B47.3070008@zytor.com","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-10-28T08:29:09Z","receivedAt":"2005-10-28T08:29:09Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"H. Peter Anvin wrote:\n> Chris Shoemaker wrote:\n> \n>>\n>> Ok, but that cache would live inside GIT_DIR an be shared with gitk,\n>> right?\n>>\n> \n> That would be bad. Don't assume that the person running gitweb (or \n> gitk, for that matter) has write permission.\n> \n\nNot necessarily in the archive, but it could support a --cache-dir \noption. If no cache-dir directive is used it could try GIT_DIR/cache and \ngo on as usual if that fails too.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"10756","messageId":"200510281116.41842.Josef.Weidendorfer@gmx.de","threadId":"2244","inReplyTo":"20051027203945.GC1622@pe.Belkin","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-10-28T09:16:40Z","receivedAt":"2005-10-28T09:16:40Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 27 October 2005 22:39, Chris Shoemaker wrote:\n> \n> I really like gitweb (thanks Kay!), but I thought it would be nice to\n> have a visual indication of patch size. I found this helpful when\n> scanning though the shortlogs.\n\nLooks nice.\nWhat about splitting this up into red (removed lines)\nand green (added lines) bars?\n\nJosef\n"},{"id":"10757","messageId":"7v3bmmvvgx.fsf@assigned-by-dhcp.cox.net","threadId":"2244","inReplyTo":"20051028005029.GA2654@pe.Belkin","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-28T09:31:26Z","receivedAt":"2005-10-28T09:31:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Shoemaker writes:\n\n> Ok, but that cache would live inside GIT_DIR an be shared with gitk,\n> right?\n\nIt is up to gitk. If your cache file format is simple, concise\nand easy to access, then it might be useful for gitk to take\nadvantage of it. Although I doubt many people would run gitk\nand gitweb on the same repository (usually the former is run on\nthe private developer repository and the latter public one).\n\nCaching the 'git-diff-tree -p | git-apply --numstat' output\nmight be useful and compact enough. I often wonder if the\ncommit page (i.e. gitweb?p=$repository;a=commit;h=$sha1) might\nbe more useful if it had diffstat drawing on each blob line at\nthe end of the page, and the output from the above pipe can be\nused for that.\n\nI wonder how big that thing would become if we cache it for the\nwhole history, using something simple and lightweight like\nberkeley db or dbm, 20-byte commit ID as the key (for now,\nignoring merges, but we could use 40-byte commit-parent ID pair\nas the key) and a list of the number of insertions and deletions\nfor affected paths as the value. If we can do it quickly\nenough, you could put the cache update in post-update hook, so\nthat every time you push into the public repository the\npatch-size cache is updated for gitweb's use. This can be done\nby the repository owner, and gitweb can stay read-only consumer\nof the information.\n\nJust in case people find this useful, here is a patch to\nimplement git-apply --numstat.\n\n ------------\n[PATCH] git-apply --numstat\n\nThe new option, --numstat, shows number of inserted and deleted\nlines for each path. It is similar to --stat output but is\nmeant to be more machine friendly by giving number of added and\ndeleted lines and unabbreviated paths.\n\nSigned-off-by: Junio C Hamano \n---\n\ngit diff\ndiff --git a/apply.c b/apply.c\nindex e5c0b7d..73dfd0c 100644\n--- a/apply.c\n+++ b/apply.c\n@@ -13,18 +13,20 @@\n // --check turns on checking that the working tree matches the\n // files that are being modified, but doesn't apply the patch\n // --stat does just a diffstat, and doesn't actually apply\n+// --numstat does numeric diffstat, and doesn't actually apply\n // --index-info shows the old and new index info for paths if available.\n //\n static int check_index = 0;\n static int write_index = 0;\n static int diffstat = 0;\n+static int numstat = 0;\n static int summary = 0;\n static int check = 0;\n static int apply = 1;\n static int show_index_info = 0;\n static int line_termination = '\\n';\n static const char apply_usage[] =\n-\"git-apply [--stat] [--summary] [--check] [--index] [--apply] [--index-info] [-z] ...\";\n+\"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--index-info] [-z] ...\";\n \n /*\n * For \"diff-stat\" like behaviour, we keep track of the biggest change\n@@ -1317,6 +1319,20 @@ static void stat_patch_list(struct patch\n \tprintf(\" %d files changed, %d insertions(+), %d deletions(-)\\n\", files, adds, dels);\n }\n \n+static void numstat_patch_list(struct patch *patch)\n+{\n+\tfor ( ; patch; patch = patch->next) { \n+\t\tconst char *name;\n+\t\tname = patch->old_name ? patch->old_name : patch->new_name;\n+\t\tprintf(\"%d\\t%d\\t\", patch->lines_added, patch->lines_deleted);\n+\t\tif (line_termination && quote_c_style(name, NULL, NULL, 0))\n+\t\t\tquote_c_style(name, NULL, stdout, 0);\n+\t\telse\n+\t\t\tfputs(name, stdout);\n+\t\tputchar('\\n');\n+\t}\n+}\n+\n static void show_file_mode_name(const char *newdelete, unsigned int mode, const char *name)\n {\n \tif (mode)\n@@ -1650,6 +1666,9 @@ static int apply_patch(int fd)\n \tif (diffstat)\n \t\tstat_patch_list(list);\n \n+\tif (numstat)\n+\t\tnumstat_patch_list(list);\n+\t\n \tif (summary)\n \t\tsummary_patch_list(list);\n \n@@ -1683,6 +1702,11 @@ int main(int argc, char **argv)\n \t\t\tdiffstat = 1;\n \t\t\tcontinue;\n \t\t}\n+\t\tif (!strcmp(arg, \"--numstat\")) {\n+\t\t\tapply = 0;\n+\t\t\tnumstat = 1;\n+\t\t\tcontinue;\n+\t\t}\n \t\tif (!strcmp(arg, \"--summary\")) {\n \t\t\tapply = 0;\n \t\t\tsummary = 1;\n"},{"id":"10759","messageId":"Pine.LNX.4.64.0510280901410.4664@g5.osdl.org","threadId":"2244","inReplyTo":"7vr7a6z4bc.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-28T16:02:28Z","receivedAt":"2005-10-28T16:02:28Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 27 Oct 2005, Junio C Hamano wrote:\n>\n> Linus Torvalds writes:\n> \n> > Well, if you do full copy detection (and break detection), then \n> > git-diff-tree will actually have effectively calculated the size of the \n> > diff of each file. It just doesn't print them (well, it does a percentage \n> > for the renames/copies).\n> \n> Unbroken in-place edit would never go through diffcore-rename,\n> so that is a gross overstatement.\n\nWell, the break detection will have _calculated_ the diff size.\n\nThe point being that all the work has been done - it's just not printed \nout.\n\n\t\tLinus\n"},{"id":"10962","messageId":"20051101233035.GB1431@pasky.or.cz","threadId":"2244","inReplyTo":"20051028023833.GA19939@pe.Belkin","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-01T23:30:35Z","receivedAt":"2005-11-01T23:30:35Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Oct 28, 2005 at 04:38:33AM CEST, I got a letter\nwhere Chris Shoemaker told me that...\n> Here's a side-by-side comparison. Open two browser tabs and flip between them:\n> \n> http://www.codesifter.com/cgi-bin/gitweb-difftreeP.cgi?p=git.git;a=shortlog\n> http://www.codesifter.com/cgi-bin/gitweb-difftreeNames.cgi?p=git.git;a=shortlog\n> \n> I've used a project you all are familar with, and that has more than\n> two files. The first page uses 'git-diff-tree -p $hash|wc -l'. The\n> second page uses 'git-diff-tree -r --name-only|wc -l'. (Oh and I have\n> a merge indicator now.)\n> \n> How do they compare for showing damage-potential? I think they both\n> do a reasonable job. I think the full patch diff is a bit better, but\n> it does cost.\n\nWhat about having the color indicate the number of affected files (let's\nsay on a blue..red scale) and the width the size of patch?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10963","messageId":"46a038f90511011533q177328fdrf4b0dd68f188282e@mail.gmail.com","threadId":"2244","inReplyTo":"20051101233035.GB1431@pasky.or.cz","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-11-01T23:33:38Z","receivedAt":"2005-11-01T23:33:38Z","isPatch":true,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/2/05, Petr Baudis wrote:\n> What about having the color indicate the number of affected files (let's\n> say on a blue..red scale) and the width the size of patch?\n\nI'm a /little bit/ colour blind on the red scale -- so I vote for 2\nbars, each half the heigth of the current bar. ;-)\n\nmartin\n"},{"id":"10966","messageId":"20051101234302.GD1431@pasky.or.cz","threadId":"2244","inReplyTo":"46a038f90511011533q177328fdrf4b0dd68f188282e@mail.gmail.com","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-01T23:43:02Z","receivedAt":"2005-11-01T23:43:02Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Nov 02, 2005 at 12:33:38AM CET, I got a letter\nwhere Martin Langhoff told me that...\n> On 11/2/05, Petr Baudis wrote:\n> > What about having the color indicate the number of affected files (let's\n> > say on a blue..red scale) and the width the size of patch?\n> \n> I'm a /little bit/ colour blind on the red scale -- so I vote for 2\n> bars, each half the heigth of the current bar. ;-)\n\nThat's certainly possible as well (if you make each of the bars of\ndifferent color), but for most people not equally visually obvious.\nPerhaps we could have a knob at the bottom of the page, but that isn't\nvery satisfying a solution either... :-(\n\nAnother possibility is to make the height dynamic and in proportion with\nthe number of affected files. Or combine both the color and dynamic\nheight. I believe changing the color to red would make it appear as\nblack for the red-color-blind people?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10967","messageId":"20051102001206.GA21671@pe.Belkin","threadId":"2244","inReplyTo":"46a038f90511011533q177328fdrf4b0dd68f188282e@mail.gmail.com","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2005-11-02T00:12:06Z","receivedAt":"2005-11-02T00:12:06Z","isPatch":true,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:\n> On 11/2/05, Petr Baudis wrote:\n> > What about having the color indicate the number of affected files (let's\n> > say on a blue..red scale) and the width the size of patch?\n> \n> I'm a /little bit/ colour blind on the red scale -- so I vote for 2\n> bars, each half the heigth of the current bar. ;-)\n\nI was going to use two bars for add vs. delete, but this could work,\ntoo. I'm intending on getting back to this ASAP, but for now my\ncvsimport problems are higher priority (see other post).\n\n-chris\n\n> \n> martin\n"},{"id":"10972","messageId":"20051102002631.GA18529@vrfy.org","threadId":"2244","inReplyTo":"20051102001206.GA21671@pe.Belkin","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-11-02T00:26:31Z","receivedAt":"2005-11-02T00:26:31Z","isPatch":true,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Tue, Nov 01, 2005 at 07:12:06PM -0500, Chris Shoemaker wrote:\n> On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:\n> > On 11/2/05, Petr Baudis wrote:\n> > > What about having the color indicate the number of affected files (let's\n> > > say on a blue..red scale) and the width the size of patch?\n> > \n> > I'm a /little bit/ colour blind on the red scale -- so I vote for 2\n> > bars, each half the heigth of the current bar. ;-)\n> \n> I was going to use two bars for add vs. delete, but this could work,\n> too. I'm intending on getting back to this ASAP, but for now my\n> cvsimport problems are higher priority (see other post).\n\nGuys, I'm not convinced, that we should make gitweb look like Konqueror. :)\n\nKay\n"},{"id":"10995","messageId":"43687414.1030702@op5.se","threadId":"2244","inReplyTo":"20051101234302.GD1431@pasky.or.cz","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-02T08:08:52Z","receivedAt":"2005-11-02T08:08:52Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Petr Baudis wrote:\n> \n> Another possibility is to make the height dynamic and in proportion with\n> the number of affected files. Or combine both the color and dynamic\n> height. I believe changing the color to red would make it appear as\n> black for the red-color-blind people?\n> \n\nColor-blindness doesn't work like that. There are no \"red-color-blind\" \npeople. It's either red-blue, red-green or blue-green and the problem \nlies in differing those colors from each other when they're close \ntogether (and, usually, intermixed). Red-green color-blindness is by far \nthe most common so it would be wise not to use those.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"11012","messageId":"Pine.LNX.4.63.0511021135450.6501@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2244","inReplyTo":"43687414.1030702@op5.se","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-02T10:37:05Z","receivedAt":"2005-11-02T10:37:05Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 2 Nov 2005, Andreas Ericsson wrote:\n\n> Color-blindness doesn't work like that. There are no \"red-color-blind\" \n> people.\n\nI do exist. I have problems focusing on red text or objects. Agreed, it is \nno \"blindness\", but it is not too seldom either.\n\nCiao,\nDscho\n"},{"id":"11013","messageId":"4368AEBB.6080609@op5.se","threadId":"2244","inReplyTo":"Pine.LNX.4.63.0511021135450.6501@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-02T12:19:07Z","receivedAt":"2005-11-02T12:19:07Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 2 Nov 2005, Andreas Ericsson wrote:\n> \n> \n>>Color-blindness doesn't work like that. There are no \"red-color-blind\" \n>>people.\n> \n> \n> I do exist. I have problems focusing on red text or objects. Agreed, it is \n> no \"blindness\", but it is not too seldom either.\n> \n\nIs that irrespective of background color?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"11014","messageId":"Pine.LNX.4.63.0511021342510.6887@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2244","inReplyTo":"4368AEBB.6080609@op5.se","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-02T12:43:57Z","receivedAt":"2005-11-02T12:43:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 2 Nov 2005, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> > \n> > On Wed, 2 Nov 2005, Andreas Ericsson wrote:\n> > \n> > \n> > > Color-blindness doesn't work like that. There are no \"red-color-blind\"\n> > > people.\n> > \n> > \n> > I do exist. I have problems focusing on red text or objects. Agreed, it is\n> > no \"blindness\", but it is not too seldom either.\n> > \n> \n> Is that irrespective of background color?\n\nMostly. (I don't remember the exact outcome of the test, but I am \ndefinitely not color blind).\n\nCiao,\nDscho\n"},{"id":"13189","messageId":"20051205000442.GB22159@pasky.or.cz","threadId":"2244","inReplyTo":"20051102001206.GA21671@pe.Belkin","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-12-05T00:04:42Z","receivedAt":"2005-12-05T00:04:42Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Nov 02, 2005 at 01:12:06AM CET, I got a letter\nwhere Chris Shoemaker said that...\n> On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:\n> > On 11/2/05, Petr Baudis wrote:\n> > > What about having the color indicate the number of affected files (let's\n> > > say on a blue..red scale) and the width the size of patch?\n> > \n> > I'm a /little bit/ colour blind on the red scale -- so I vote for 2\n> > bars, each half the heigth of the current bar. ;-)\n> \n> I was going to use two bars for add vs. delete, but this could work,\n> too. I'm intending on getting back to this ASAP, but for now my\n> cvsimport problems are higher priority (see other post).\n\nIs there any progress, by the way?\n\nIf you didn't manage to finish it, no big deal - but it would be great\nto have at least the last version you screenshotted, since IIRC I\ncouldn't find that one either, and I would like to play with it a bit.\n\nThanks,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"13197","messageId":"20051205010335.GA4073@pe.Belkin","threadId":"2244","inReplyTo":"20051205000442.GB22159@pasky.or.cz","subject":"Re: [PATCH gitweb] Visually indicating patch size with horizontal bars","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2005-12-05T01:03:35Z","receivedAt":"2005-12-05T01:03:35Z","isPatch":true,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Mon, Dec 05, 2005 at 01:04:42AM +0100, Petr Baudis wrote:\n> Dear diary, on Wed, Nov 02, 2005 at 01:12:06AM CET, I got a letter\n> where Chris Shoemaker said that...\n> > On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:\n> > > On 11/2/05, Petr Baudis wrote:\n> > > > What about having the color indicate the number of affected files (let's\n> > > > say on a blue..red scale) and the width the size of patch?\n> > > \n> > > I'm a /little bit/ colour blind on the red scale -- so I vote for 2\n> > > bars, each half the heigth of the current bar. ;-)\n> > \n> > I was going to use two bars for add vs. delete, but this could work,\n> > too. I'm intending on getting back to this ASAP, but for now my\n> > cvsimport problems are higher priority (see other post).\n> \n> Is there any progress, by the way?\n\nA little. I decided to follow Junio's suggestion of caching the\nresult of \"git-diff-tree -r -p $commit | git-apply --numstat\" in a\nBerkeleyDB. (I liked the idea of reusing the cached results on the\ncommit page, too.) I got a script to populate the cache, then I\nsuspect could be easily adapting into a commit-hook. Then I started\nworking on the gitweb part and tried to follow another suggestion\n(Kay's, I think.) to use CSS instead of (yet another) embedded .png.\n\nThis is where I got hung up: I discovered something strange (to me, at\nleast) about CSS/html: I'm using the in the fifth column of\nthe shortlog. I tried to use an anchor tag for the added count and\none for the deleted count. Setting \"display:block\" and the different\nbackground-colors works (produces stacked horizontal bars), as does\nsetting various widths (an essential point), but *ONLY* using \"width\"\nin the CSS. Using width anchor attribute simply doesn't work.\n\nHonestly, html/css is not my strong suit and neither is perl, although\nthe BerkeleyDB perl API seemed simple enough.\n\n> If you didn't manage to finish it, no big deal - but it would be great\n> to have at least the last version you screenshotted, since IIRC I\n> couldn't find that one either, and I would like to play with it a bit.\n\nI'm happy for anyone to take this over. Since my excursion into css\ndidn't really work, I'd suggest starting with the gitweb-difftreeP.cgi\nversion. I will send you (and anyone else who asks) that file and the\ncache population script.\n\n-chris\n"}]}