# [PATCH gitweb] Visually indicating patch size with horizontal bars 27 messages from 2005-10-27 to 2005-12-05. Participants: Chris Shoemaker, Junio C Hamano, Linus Torvalds, Martin Langhoff, H. Peter Anvin, Kay Sievers, Andreas Ericsson, Josef Weidendorfer, Petr Baudis, Johannes Schindelin. Thread: https://gitlist.dev/t/2244 ## Chris Shoemaker, 2005-10-27 20:39 Subject: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <20051027203945.GC1622@pe.Belkin> URL: https://gitlist.dev/e/20051027203945.GC1622%40pe.Belkin ``` I really like gitweb (thanks Kay!), but I thought it would be nice to have a visual indication of patch size. I found this helpful when scanning though the shortlogs. To see what it looks like with the gitweb for gitweb (meta-gitweb?) goto: http://www.codesifter.com/cgi-bin/gitweb.cgi?p=gitweb.git;a=shortlog I rather like the look of what I've hacked up (the enclosed patch), but it should be considered as just a prototype: it only affects the shortlog, it's horribly inefficient, and I don't really do perl. :) If anyone thinks this is a good feature, then please tell me an efficient way to get some heuristic of the patch size. Right now, I'm using: GIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l which is pretty slow. Any suggestions? -chris Subject: [PATCH] initial hack at horizontal bars indicating patch size --- gitweb.cgi | 38 +++++++++++++++++++++++++++++++++++++- 1 files changed, 37 insertions(+), 1 deletions(-) c8d45f9a3cfdd7080a57e0de315f3ab9475f60bf diff --git a/gitweb.cgi b/gitweb.cgi --- a/gitweb.cgi +++ b/gitweb.cgi @@ -53,6 +53,9 @@ if (defined $action) { } elsif ($action eq "opml") { git_opml(); exit; + } elsif ($action eq "bar.png") { + git_bar_png(); + exit; } } @@ -358,6 +361,16 @@ sub git_get_type { return $type; } +sub git_get_commit_size { + my $hash = shift; + + open my $fd, "-|", "GIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l" or return; + my $size = <$fd>; + close $fd or return; + chomp $size; + return $size; +} + sub git_read_hash { my $path = shift; @@ -719,6 +732,21 @@ sub git_logo { "\x12\x1c\x9a\xfe\x00\x00\x00\x00\x49\x45\x4e\x44\xae\x42\x60\x82"; } +# git_bar_png (cached in browser for one day) +sub git_bar_png { + print $cgi->header(-type => 'image/png', -expires => '+1d'); + # cat bar.png | hexdump -e '"q" 16/1 "w%02x" "q . \n"' | + # sed 's/w/\\x/g' | sed 's/q/"/g' +print "\x89\x50\x4e\x47\x0d\x0a\x1a\x0a\x00\x00\x00\x0d\x49\x48\x44\x52" . +"\x00\x00\x00\x01\x00\x00\x00\x0c\x08\x02\x00\x00\x00\x2c\xe9\x40" . +"\x00\x00\x00\x00\x3b\x49\x44\x41\x54\x08\x1d\x01\x30\x00\xcf\xff" . +"\x00\xba\xba\xff\x02\xf1\xf1\x00\x02\xf2\xf2\x00\x02\xf1\xf2\x00" . +"\x02\xf2\xf1\x00\x02\xf1\xf1\x00\x02\xf2\xf1\x00\x02\xf1\xf1\x00" . +"\x02\xf1\xf2\x00\x02\xf1\xf1\x00\x02\xf2\xf2\x00\x02\xf2\xf1\x00" . +"\x45\x85\x17\x49\x14\x70\x67\xdb\x00\x00\x00\x00\x49\x45\x4e\x44" . +"\xae\x42\x60\x82"; +} + sub get_file_owner { my $path = shift; @@ -2280,8 +2308,16 @@ sub git_shortlog { "" . $cgi->a({-href => "$my_uri?p=$project;a=commit;h=$commit"}, "commit") . " | " . $cgi->a({-href => "$my_uri?p=$project;a=commitdiff;h=$commit"}, "commitdiff") . - "\n" . + "\n"; + my $scale = 100; + my $stretch = 32; + # commits of size 1.7*$scale will be $stretch pixels wide + my $size = int(log((git_get_commit_size($commit)+$scale)/$scale)*$stretch); + print "" . + "" . + "" . ""; + } if ($#revlist >= (100 * ($page+1)-1)) { print "\n" . ``` ## Junio C Hamano, 2005-10-27 22:02 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <7vfyqm1uvx.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfyqm1uvx.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20051027203945.GC1622@pe.Belkin> ``` Chris Shoemaker writes: > If anyone thinks this is a good feature, then please tell me an > efficient way to get some heuristic of the patch size. > > Right now, I'm using: > > GIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l > > which is pretty slow. Any suggestions? * do we really want to know the number of lines? sometimes the number of pahts that are affected is more useful than number of lines when assessing the damage, which can be done with 'git-diff-tree --name-only'. * cache the result -- they never change. An interesting question is what to do with merges, but probably we can just ignore it for now. ``` ## Chris Shoemaker, 2005-10-27 23:48 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <20051027234813.GA512@pe.Belkin> URL: https://gitlist.dev/e/20051027234813.GA512%40pe.Belkin In-Reply-To: <7vfyqm1uvx.fsf@assigned-by-dhcp.cox.net> ``` On Thu, Oct 27, 2005 at 03:02:10PM -0700, Junio C Hamano wrote: > Chris Shoemaker writes: > > > If anyone thinks this is a good feature, then please tell me an > > efficient way to get some heuristic of the patch size. > > > > Right now, I'm using: > > > > GIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l > > > > which is pretty slow. Any suggestions? > > * do we really want to know the number of lines? sometimes the > number of pahts that are affected is more useful than number > of lines when assessing the damage, which can be done with > 'git-diff-tree --name-only'. That only shows the top-level names, so when 100s of files changes in a subdir it looks just like one entry. It's ok when there's no subdirs, but it just doesn't work when 95% of the code is under, e.g. src/. > > * cache the result -- they never change. True. Maybe gitk and gitweb can share a cache containing the tree diffs. Or maybe git-core can cache tree diffs? > > An interesting question is what to do with merges, but probably > we can just ignore it for now. It's trivial to, e.g. use a different image for merges, maybe based on # of parents? But, in general, is there interest in a visual indicator of commit size and/or type in gitweb? -chris ``` ## Linus Torvalds, 2005-10-28 00:12 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0510271709120.4664%40g5.osdl.org In-Reply-To: <20051027234813.GA512@pe.Belkin> ``` On Thu, 27 Oct 2005, Chris Shoemaker wrote: > > > > * do we really want to know the number of lines? sometimes the > > number of pahts that are affected is more useful than number > > of lines when assessing the damage, which can be done with > > 'git-diff-tree --name-only'. > > That only shows the top-level names, so when 100s of files changes in > a subdir it looks just like one entry. It's ok when there's no > subdirs, but it just doesn't work when 95% of the code is under, > e.g. src/. Add the "-r" flag to do the recursive thing, ie git-diff-tree -r --name-only should do the right thing. > True. Maybe gitk and gitweb can share a cache containing the tree > diffs. Or maybe git-core can cache tree diffs? Creating them is fast enough if there is no IO. Make sure your project is packed, and you should be ok. The expensive part is the "-p" thing to create patches. If you avoid the patch creation, you should be ok. > But, in general, is there interest in a visual indicator of commit > size and/or type in gitweb? I kind of like it, but I'm not sure how useful it is, and maybe it does really want the whole patch size (not just how many files it touches). That's where caching might save your *ss. Linus ``` ## Chris Shoemaker, 2005-10-28 00:50 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <20051028005029.GA2654@pe.Belkin> URL: https://gitlist.dev/e/20051028005029.GA2654%40pe.Belkin In-Reply-To: ``` On Thu, Oct 27, 2005 at 05:12:33PM -0700, Linus Torvalds wrote: > Add the "-r" flag to do the recursive thing, ie > > git-diff-tree -r --name-only > > should do the right thing. Ah, yes, it does. Thanks. > > True. Maybe gitk and gitweb can share a cache containing the tree > > diffs. Or maybe git-core can cache tree diffs? > > Creating them is fast enough if there is no IO. Make sure your project is > packed, and you should be ok. > > The expensive part is the "-p" thing to create patches. If you avoid the > patch creation, you should be ok. git-diff-tree -r --name-only is pretty quick and it actually does a halfway reasonable job of representing damage-potential. > > But, in general, is there interest in a visual indicator of commit > > size and/or type in gitweb? > > I kind of like it, but I'm not sure how useful it is, and maybe it does > really want the whole patch size (not just how many files it touches). Hard to say. Neither one is going to be perfect, so I'm ok with settling for the cheap one if it's halfway reasonable. I think I'll mock up the merge indicator and see if there's any value added there. So, what's the best way to detect merges? Maybe see if 'git-cat-file commit $hash | grep ^parent | wc -l' is greater than 1? > That's where caching might save your *ss. Ok, but that cache would live inside GIT_DIR an be shared with gitk, right? -chris ``` ## Martin Langhoff, 2005-10-28 01:08 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <46a038f90510271808n36a75676y9f50109db43b5ab@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90510271808n36a75676y9f50109db43b5ab%40mail.gmail.com In-Reply-To: <20051028005029.GA2654@pe.Belkin> ``` On 10/28/05, Chris Shoemaker wrote: > So, what's the best way to detect merges? Maybe see if > 'git-cat-file commit $hash | grep ^parent | wc -l' is greater than 1? > > > That's where caching might save your *ss. > > Ok, but that cache would live inside GIT_DIR an be shared with gitk, > right? gitweb should have any caches it wants, regardless of gitk, methinks. I very rarely run gitk and gitweb on the same repo. The repos where I run gitk are all development repos, on my desktop machine or laptop. gitweb runs only on the webserver where I publish those... So it may be practical to have a common cache format, but unlikely that both programs will use the same cached data in practice... martin ``` ## H. Peter Anvin, 2005-10-28 01:13 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <43617B47.3070008@zytor.com> URL: https://gitlist.dev/e/43617B47.3070008%40zytor.com In-Reply-To: <20051028005029.GA2654@pe.Belkin> ``` Chris Shoemaker wrote: > > Ok, but that cache would live inside GIT_DIR an be shared with gitk, > right? > That would be bad. Don't assume that the person running gitweb (or gitk, for that matter) has write permission. -hpa ``` ## Martin Langhoff, 2005-10-28 01:16 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <46a038f90510271816i26389d5cqe136f515007ca057@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90510271816i26389d5cqe136f515007ca057%40mail.gmail.com In-Reply-To: <7vfyqm1uvx.fsf@assigned-by-dhcp.cox.net> ``` On 10/28/05, Junio C Hamano wrote: > > which is pretty slow. Any suggestions? > > * do we really want to know the number of lines? What about both? And sugar (rename detection) on top! ;-) If you try an find the largest commit (by line count) in the gitweb revision history, you bump into the gitweb.pl -> gitweb.cgi rename. cheers, martin ``` ## Kay Sievers, 2005-10-28 01:56 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <20051028015642.GA31822@vrfy.org> URL: https://gitlist.dev/e/20051028015642.GA31822%40vrfy.org In-Reply-To: <20051027203945.GC1622@pe.Belkin> ``` On Thu, Oct 27, 2005 at 04:39:45PM -0400, Chris Shoemaker wrote: > > I really like gitweb (thanks Kay!), but I thought it would be nice to > have a visual indication of patch size. I found this helpful when > scanning though the shortlogs. This looks nice, but if the patch size tells you something important, your commit subjects are probably too short or wrong. :) > To see what it looks like with the gitweb for gitweb (meta-gitweb?) > goto: > > http://www.codesifter.com/cgi-bin/gitweb.cgi?p=gitweb.git;a=shortlog > > I rather like the look of what I've hacked up (the enclosed patch), > but it should be considered as just a prototype: it only affects the > shortlog, it's horribly inefficient, and I don't really do perl. :) > > If anyone thinks this is a good feature, then please tell me an > efficient way to get some heuristic of the patch size. You may try to use CSS instead of an embedded picture to draw the bar, just like the RSS logo in the footer, which is simple CSS rendered in the browser. Kay ``` ## Linus Torvalds, 2005-10-28 02:38 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0510271933140.4664%40g5.osdl.org In-Reply-To: <46a038f90510271816i26389d5cqe136f515007ca057@mail.gmail.com> ``` On Fri, 28 Oct 2005, Martin Langhoff wrote: > > On 10/28/05, Junio C Hamano wrote: > > > which is pretty slow. Any suggestions? > > > > * do we really want to know the number of lines? > > What about both? And sugar (rename detection) on top! ;-) Well, if you do full copy detection (and break detection), then git-diff-tree will actually have effectively calculated the size of the diff of each file. It just doesn't print them (well, it does a percentage for the renames/copies). So you could make git-diff-tree tell you how big the patch was, without actually generating a patch at all. It will be quite a bit more expensive than just a plain "git-diff-tree -r --name-only", but if you cache the result is might be quite acceptable. Caching the result might be as simple as just telling the caching web-server that the result is static and never changes - no need to cache things inside of gitweb itself. Just set expiration to "never". Anybody wants to add a new output format to git-diff-tree that outputs how big the changes are in absolute terms (rather than the "similarity index", which is obviously relative to the original size of the file in question)? Linus ``` ## Chris Shoemaker, 2005-10-28 02:38 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <20051028023833.GA19939@pe.Belkin> URL: https://gitlist.dev/e/20051028023833.GA19939%40pe.Belkin In-Reply-To: <20051028015642.GA31822@vrfy.org> ``` On Fri, Oct 28, 2005 at 03:56:42AM +0200, Kay Sievers wrote: > On Thu, Oct 27, 2005 at 04:39:45PM -0400, Chris Shoemaker wrote: > > > > I really like gitweb (thanks Kay!), but I thought it would be nice to > > have a visual indication of patch size. I found this helpful when > > scanning though the shortlogs. > > This looks nice, but if the patch size tells you something important, > your commit subjects are probably too short or wrong. :) Yeah, some people write lousy commit subjects. But me? Nooo, /never/. :) > You may try to use CSS instead of an embedded picture to draw the bar, > just like the RSS logo in the footer, which is simple CSS rendered in the > browser. I'll look into that, but the cost wasn't in the image; it was in the width calculation. Here's a side-by-side comparison. Open two browser tabs and flip between them: http://www.codesifter.com/cgi-bin/gitweb-difftreeP.cgi?p=git.git;a=shortlog http://www.codesifter.com/cgi-bin/gitweb-difftreeNames.cgi?p=git.git;a=shortlog I've used a project you all are familar with, and that has more than two files. The first page uses 'git-diff-tree -p $hash|wc -l'. The second page uses 'git-diff-tree -r --name-only|wc -l'. (Oh and I have a merge indicator now.) How do they compare for showing damage-potential? I think they both do a reasonable job. I think the full patch diff is a bit better, but it does cost. -chris ``` ## Junio C Hamano, 2005-10-28 03:52 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <7vr7a6z4bc.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr7a6z4bc.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds writes: > Well, if you do full copy detection (and break detection), then > git-diff-tree will actually have effectively calculated the size of the > diff of each file. It just doesn't print them (well, it does a percentage > for the renames/copies). Unbroken in-place edit would never go through diffcore-rename, so that is a gross overstatement. But we could if we wanted to. I do not know how useful it would be, but if somebody wants to do it, I think the best strategy is to do as a separate diffcore backend that comes after diffcore_rename() runs, and do the similarity estimator only on filepairs that rename/copy did not touch. ``` ## Andreas Ericsson, 2005-10-28 08:29 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <4361E155.2020201@op5.se> URL: https://gitlist.dev/e/4361E155.2020201%40op5.se In-Reply-To: <43617B47.3070008@zytor.com> ``` H. Peter Anvin wrote: > Chris Shoemaker wrote: > >> >> Ok, but that cache would live inside GIT_DIR an be shared with gitk, >> right? >> > > That would be bad. Don't assume that the person running gitweb (or > gitk, for that matter) has write permission. > Not necessarily in the archive, but it could support a --cache-dir option. If no cache-dir directive is used it could try GIT_DIR/cache and go on as usual if that fails too. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Josef Weidendorfer, 2005-10-28 09:16 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <200510281116.41842.Josef.Weidendorfer@gmx.de> URL: https://gitlist.dev/e/200510281116.41842.Josef.Weidendorfer%40gmx.de In-Reply-To: <20051027203945.GC1622@pe.Belkin> ``` On Thursday 27 October 2005 22:39, Chris Shoemaker wrote: > > I really like gitweb (thanks Kay!), but I thought it would be nice to > have a visual indication of patch size. I found this helpful when > scanning though the shortlogs. Looks nice. What about splitting this up into red (removed lines) and green (added lines) bars? Josef ``` ## Junio C Hamano, 2005-10-28 09:31 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <7v3bmmvvgx.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3bmmvvgx.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20051028005029.GA2654@pe.Belkin> ``` Chris Shoemaker writes: > Ok, but that cache would live inside GIT_DIR an be shared with gitk, > right? It is up to gitk. If your cache file format is simple, concise and easy to access, then it might be useful for gitk to take advantage of it. Although I doubt many people would run gitk and gitweb on the same repository (usually the former is run on the private developer repository and the latter public one). Caching the 'git-diff-tree -p | git-apply --numstat' output might be useful and compact enough. I often wonder if the commit page (i.e. gitweb?p=$repository;a=commit;h=$sha1) might be more useful if it had diffstat drawing on each blob line at the end of the page, and the output from the above pipe can be used for that. I wonder how big that thing would become if we cache it for the whole history, using something simple and lightweight like berkeley db or dbm, 20-byte commit ID as the key (for now, ignoring merges, but we could use 40-byte commit-parent ID pair as the key) and a list of the number of insertions and deletions for affected paths as the value. If we can do it quickly enough, you could put the cache update in post-update hook, so that every time you push into the public repository the patch-size cache is updated for gitweb's use. This can be done by the repository owner, and gitweb can stay read-only consumer of the information. Just in case people find this useful, here is a patch to implement git-apply --numstat. ------------ [PATCH] git-apply --numstat The new option, --numstat, shows number of inserted and deleted lines for each path. It is similar to --stat output but is meant to be more machine friendly by giving number of added and deleted lines and unabbreviated paths. Signed-off-by: Junio C Hamano --- git diff diff --git a/apply.c b/apply.c index e5c0b7d..73dfd0c 100644 --- a/apply.c +++ b/apply.c @@ -13,18 +13,20 @@ // --check turns on checking that the working tree matches the // files that are being modified, but doesn't apply the patch // --stat does just a diffstat, and doesn't actually apply +// --numstat does numeric diffstat, and doesn't actually apply // --index-info shows the old and new index info for paths if available. // static int check_index = 0; static int write_index = 0; static int diffstat = 0; +static int numstat = 0; static int summary = 0; static int check = 0; static int apply = 1; static int show_index_info = 0; static int line_termination = '\n'; static const char apply_usage[] = -"git-apply [--stat] [--summary] [--check] [--index] [--apply] [--index-info] [-z] ..."; +"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--index-info] [-z] ..."; /* * For "diff-stat" like behaviour, we keep track of the biggest change @@ -1317,6 +1319,20 @@ static void stat_patch_list(struct patch printf(" %d files changed, %d insertions(+), %d deletions(-)\n", files, adds, dels); } +static void numstat_patch_list(struct patch *patch) +{ + for ( ; patch; patch = patch->next) { + const char *name; + name = patch->old_name ? patch->old_name : patch->new_name; + printf("%d\t%d\t", patch->lines_added, patch->lines_deleted); + if (line_termination && quote_c_style(name, NULL, NULL, 0)) + quote_c_style(name, NULL, stdout, 0); + else + fputs(name, stdout); + putchar('\n'); + } +} + static void show_file_mode_name(const char *newdelete, unsigned int mode, const char *name) { if (mode) @@ -1650,6 +1666,9 @@ static int apply_patch(int fd) if (diffstat) stat_patch_list(list); + if (numstat) + numstat_patch_list(list); + if (summary) summary_patch_list(list); @@ -1683,6 +1702,11 @@ int main(int argc, char **argv) diffstat = 1; continue; } + if (!strcmp(arg, "--numstat")) { + apply = 0; + numstat = 1; + continue; + } if (!strcmp(arg, "--summary")) { apply = 0; summary = 1; ``` ## Linus Torvalds, 2005-10-28 16:02 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0510280901410.4664%40g5.osdl.org In-Reply-To: <7vr7a6z4bc.fsf@assigned-by-dhcp.cox.net> ``` On Thu, 27 Oct 2005, Junio C Hamano wrote: > > Linus Torvalds writes: > > > Well, if you do full copy detection (and break detection), then > > git-diff-tree will actually have effectively calculated the size of the > > diff of each file. It just doesn't print them (well, it does a percentage > > for the renames/copies). > > Unbroken in-place edit would never go through diffcore-rename, > so that is a gross overstatement. Well, the break detection will have _calculated_ the diff size. The point being that all the work has been done - it's just not printed out. Linus ``` ## Petr Baudis, 2005-11-01 23:30 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <20051101233035.GB1431@pasky.or.cz> URL: https://gitlist.dev/e/20051101233035.GB1431%40pasky.or.cz In-Reply-To: <20051028023833.GA19939@pe.Belkin> ``` Dear diary, on Fri, Oct 28, 2005 at 04:38:33AM CEST, I got a letter where Chris Shoemaker told me that... > Here's a side-by-side comparison. Open two browser tabs and flip between them: > > http://www.codesifter.com/cgi-bin/gitweb-difftreeP.cgi?p=git.git;a=shortlog > http://www.codesifter.com/cgi-bin/gitweb-difftreeNames.cgi?p=git.git;a=shortlog > > I've used a project you all are familar with, and that has more than > two files. The first page uses 'git-diff-tree -p $hash|wc -l'. The > second page uses 'git-diff-tree -r --name-only|wc -l'. (Oh and I have > a merge indicator now.) > > How do they compare for showing damage-potential? I think they both > do a reasonable job. I think the full patch diff is a bit better, but > it does cost. What about having the color indicate the number of affected files (let's say on a blue..red scale) and the width the size of patch? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## Martin Langhoff, 2005-11-01 23:33 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <46a038f90511011533q177328fdrf4b0dd68f188282e@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90511011533q177328fdrf4b0dd68f188282e%40mail.gmail.com In-Reply-To: <20051101233035.GB1431@pasky.or.cz> ``` On 11/2/05, Petr Baudis wrote: > What about having the color indicate the number of affected files (let's > say on a blue..red scale) and the width the size of patch? I'm a /little bit/ colour blind on the red scale -- so I vote for 2 bars, each half the heigth of the current bar. ;-) martin ``` ## Petr Baudis, 2005-11-01 23:43 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <20051101234302.GD1431@pasky.or.cz> URL: https://gitlist.dev/e/20051101234302.GD1431%40pasky.or.cz In-Reply-To: <46a038f90511011533q177328fdrf4b0dd68f188282e@mail.gmail.com> ``` Dear diary, on Wed, Nov 02, 2005 at 12:33:38AM CET, I got a letter where Martin Langhoff told me that... > On 11/2/05, Petr Baudis wrote: > > What about having the color indicate the number of affected files (let's > > say on a blue..red scale) and the width the size of patch? > > I'm a /little bit/ colour blind on the red scale -- so I vote for 2 > bars, each half the heigth of the current bar. ;-) That's certainly possible as well (if you make each of the bars of different color), but for most people not equally visually obvious. Perhaps we could have a knob at the bottom of the page, but that isn't very satisfying a solution either... :-( Another possibility is to make the height dynamic and in proportion with the number of affected files. Or combine both the color and dynamic height. I believe changing the color to red would make it appear as black for the red-color-blind people? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## Chris Shoemaker, 2005-11-02 00:12 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <20051102001206.GA21671@pe.Belkin> URL: https://gitlist.dev/e/20051102001206.GA21671%40pe.Belkin In-Reply-To: <46a038f90511011533q177328fdrf4b0dd68f188282e@mail.gmail.com> ``` On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote: > On 11/2/05, Petr Baudis wrote: > > What about having the color indicate the number of affected files (let's > > say on a blue..red scale) and the width the size of patch? > > I'm a /little bit/ colour blind on the red scale -- so I vote for 2 > bars, each half the heigth of the current bar. ;-) I was going to use two bars for add vs. delete, but this could work, too. I'm intending on getting back to this ASAP, but for now my cvsimport problems are higher priority (see other post). -chris > > martin ``` ## Kay Sievers, 2005-11-02 00:26 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <20051102002631.GA18529@vrfy.org> URL: https://gitlist.dev/e/20051102002631.GA18529%40vrfy.org In-Reply-To: <20051102001206.GA21671@pe.Belkin> ``` On Tue, Nov 01, 2005 at 07:12:06PM -0500, Chris Shoemaker wrote: > On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote: > > On 11/2/05, Petr Baudis wrote: > > > What about having the color indicate the number of affected files (let's > > > say on a blue..red scale) and the width the size of patch? > > > > I'm a /little bit/ colour blind on the red scale -- so I vote for 2 > > bars, each half the heigth of the current bar. ;-) > > I was going to use two bars for add vs. delete, but this could work, > too. I'm intending on getting back to this ASAP, but for now my > cvsimport problems are higher priority (see other post). Guys, I'm not convinced, that we should make gitweb look like Konqueror. :) Kay ``` ## Andreas Ericsson, 2005-11-02 08:08 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <43687414.1030702@op5.se> URL: https://gitlist.dev/e/43687414.1030702%40op5.se In-Reply-To: <20051101234302.GD1431@pasky.or.cz> ``` Petr Baudis wrote: > > Another possibility is to make the height dynamic and in proportion with > the number of affected files. Or combine both the color and dynamic > height. I believe changing the color to red would make it appear as > black for the red-color-blind people? > Color-blindness doesn't work like that. There are no "red-color-blind" people. It's either red-blue, red-green or blue-green and the problem lies in differing those colors from each other when they're close together (and, usually, intermixed). Red-green color-blindness is by far the most common so it would be wise not to use those. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Johannes Schindelin, 2005-11-02 10:37 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0511021135450.6501%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <43687414.1030702@op5.se> ``` Hi, On Wed, 2 Nov 2005, Andreas Ericsson wrote: > Color-blindness doesn't work like that. There are no "red-color-blind" > people. I do exist. I have problems focusing on red text or objects. Agreed, it is no "blindness", but it is not too seldom either. Ciao, Dscho ``` ## Andreas Ericsson, 2005-11-02 12:19 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <4368AEBB.6080609@op5.se> URL: https://gitlist.dev/e/4368AEBB.6080609%40op5.se In-Reply-To: ``` Johannes Schindelin wrote: > Hi, > > On Wed, 2 Nov 2005, Andreas Ericsson wrote: > > >>Color-blindness doesn't work like that. There are no "red-color-blind" >>people. > > > I do exist. I have problems focusing on red text or objects. Agreed, it is > no "blindness", but it is not too seldom either. > Is that irrespective of background color? -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Johannes Schindelin, 2005-11-02 12:43 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0511021342510.6887%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <4368AEBB.6080609@op5.se> ``` Hi, On Wed, 2 Nov 2005, Andreas Ericsson wrote: > Johannes Schindelin wrote: > > > > On Wed, 2 Nov 2005, Andreas Ericsson wrote: > > > > > > > Color-blindness doesn't work like that. There are no "red-color-blind" > > > people. > > > > > > I do exist. I have problems focusing on red text or objects. Agreed, it is > > no "blindness", but it is not too seldom either. > > > > Is that irrespective of background color? Mostly. (I don't remember the exact outcome of the test, but I am definitely not color blind). Ciao, Dscho ``` ## Petr Baudis, 2005-12-05 00:04 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <20051205000442.GB22159@pasky.or.cz> URL: https://gitlist.dev/e/20051205000442.GB22159%40pasky.or.cz In-Reply-To: <20051102001206.GA21671@pe.Belkin> ``` Dear diary, on Wed, Nov 02, 2005 at 01:12:06AM CET, I got a letter where Chris Shoemaker said that... > On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote: > > On 11/2/05, Petr Baudis wrote: > > > What about having the color indicate the number of affected files (let's > > > say on a blue..red scale) and the width the size of patch? > > > > I'm a /little bit/ colour blind on the red scale -- so I vote for 2 > > bars, each half the heigth of the current bar. ;-) > > I was going to use two bars for add vs. delete, but this could work, > too. I'm intending on getting back to this ASAP, but for now my > cvsimport problems are higher priority (see other post). Is there any progress, by the way? If you didn't manage to finish it, no big deal - but it would be great to have at least the last version you screenshotted, since IIRC I couldn't find that one either, and I would like to play with it a bit. Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## Chris Shoemaker, 2005-12-05 01:03 Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars Message-ID: <20051205010335.GA4073@pe.Belkin> URL: https://gitlist.dev/e/20051205010335.GA4073%40pe.Belkin In-Reply-To: <20051205000442.GB22159@pasky.or.cz> ``` On Mon, Dec 05, 2005 at 01:04:42AM +0100, Petr Baudis wrote: > Dear diary, on Wed, Nov 02, 2005 at 01:12:06AM CET, I got a letter > where Chris Shoemaker said that... > > On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote: > > > On 11/2/05, Petr Baudis wrote: > > > > What about having the color indicate the number of affected files (let's > > > > say on a blue..red scale) and the width the size of patch? > > > > > > I'm a /little bit/ colour blind on the red scale -- so I vote for 2 > > > bars, each half the heigth of the current bar. ;-) > > > > I was going to use two bars for add vs. delete, but this could work, > > too. I'm intending on getting back to this ASAP, but for now my > > cvsimport problems are higher priority (see other post). > > Is there any progress, by the way? A little. I decided to follow Junio's suggestion of caching the result of "git-diff-tree -r -p $commit | git-apply --numstat" in a BerkeleyDB. (I liked the idea of reusing the cached results on the commit page, too.) I got a script to populate the cache, then I suspect could be easily adapting into a commit-hook. Then I started working on the gitweb part and tried to follow another suggestion (Kay's, I think.) to use CSS instead of (yet another) embedded .png. This is where I got hung up: I discovered something strange (to me, at least) about CSS/html: I'm using the in the fifth column of the shortlog. I tried to use an anchor tag for the added count and one for the deleted count. Setting "display:block" and the different background-colors works (produces stacked horizontal bars), as does setting various widths (an essential point), but *ONLY* using "width" in the CSS. Using width anchor attribute simply doesn't work. Honestly, html/css is not my strong suit and neither is perl, although the BerkeleyDB perl API seemed simple enough. > If you didn't manage to finish it, no big deal - but it would be great > to have at least the last version you screenshotted, since IIRC I > couldn't find that one either, and I would like to play with it a bit. I'm happy for anyone to take this over. Since my excursion into css didn't really work, I'd suggest starting with the gitweb-difftreeP.cgi version. I will send you (and anyone else who asks) that file and the cache population script. -chris ```