threads / patch / 2244

patchVisually indicating patch size with horizontal bars

Subject: [PATCH gitweb] Visually indicating patch size with horizontal bars

## tl;dr

27 messages between Oct 27, 2005 and Dec 5, 2005. Diffs are folded; open one to read it.

replies: 26people: 10as markdown or json

Chris Shoemaker· Oct 27, 2005, 20:39 UTC · lore

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
Show changes to gitweb.cgi +37 −1
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 {
 		      "<td class=\"link\">" .
 		      $cgi->a({-href => "$my_uri?p=$project;a=commit;h=$commit"}, "commit") .
 		      " | " . $cgi->a({-href => "$my_uri?p=$project;a=commitdiff;h=$commit"}, "commitdiff") .
-		      "</td>\n" .
+		      "</td>\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 "<td class=\"bar\">" .
+		      "<img src=\"$my_uri?a=bar.png\" width=\"$size\" height=\"12\"/>" .
+		      "</td>" .
 		      "</tr>";
+
 	}
 	if ($#revlist >= (100 * ($page+1)-1)) {
 		print "<tr>\n" .
Junio C Hamano· Oct 27, 2005, 22:02 UTC · re: Chris Shoemaker · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

Chris Shoemaker <c.shoemaker@cox.net> writes:
Show 8 quoted lines
> 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· Oct 27, 2005, 23:48 UTC · re: Junio C Hamano · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On Thu, Oct 27, 2005 at 03:02:10PM -0700, Junio C Hamano wrote:
Show 15 quoted lines
> Chris Shoemaker <c.shoemaker@cox.net> 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· Oct 28, 2005, 00:12 UTC · re: Chris Shoemaker · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On Thu, 27 Oct 2005, Chris Shoemaker wrote:
Show 10 quoted lines
> > 
> > * 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· Oct 28, 2005, 00:50 UTC · re: Linus Torvalds · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On Thu, Oct 27, 2005 at 05:12:33PM -0700, Linus Torvalds wrote:
Show 5 quoted lines
> 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.
Show 8 quoted lines
> > 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.

Show 5 quoted lines
> > 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· Oct 28, 2005, 01:08 UTC · re: Chris Shoemaker · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On 10/28/05, Chris Shoemaker <c.shoemaker@cox.net> wrote:
Show 7 quoted lines
> 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· Oct 28, 2005, 01:13 UTC · re: Chris Shoemaker · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

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
Andreas Ericsson· Oct 28, 2005, 08:29 UTC · re: H. Peter Anvin · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

H. Peter Anvin wrote:
Show 10 quoted lines
> 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
Junio C Hamano· Oct 28, 2005, 09:31 UTC · re: Chris Shoemaker · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

Chris Shoemaker <c.shoemaker@cox.net> 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 <junkio@cox.net>
---
git diff
Show changes to apply.c +25 −1
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] <patch>...";
+"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--index-info] [-z] <patch>...";
 
 /*
  * 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;
Martin Langhoff· Oct 28, 2005, 01:16 UTC · re: Junio C Hamano · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On 10/28/05, Junio C Hamano <junkio@cox.net> 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
Linus Torvalds· Oct 28, 2005, 02:38 UTC · re: Martin Langhoff · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On Fri, 28 Oct 2005, Martin Langhoff wrote:
Show 7 quoted lines
>
> On 10/28/05, Junio C Hamano <junkio@cox.net> 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
Junio C Hamano· Oct 28, 2005, 03:52 UTC · re: Linus Torvalds · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

Linus Torvalds <torvalds@osdl.org> 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.

Linus Torvalds· Oct 28, 2005, 16:02 UTC · re: Junio C Hamano · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On Thu, 27 Oct 2005, Junio C Hamano wrote:
Show 10 quoted lines
>
> Linus Torvalds <torvalds@osdl.org> 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
Kay Sievers· Oct 28, 2005, 01:56 UTC · re: Chris Shoemaker · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

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. :)

Show 11 quoted lines
> 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
Chris Shoemaker· Oct 28, 2005, 02:38 UTC · re: Kay Sievers · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On Fri, Oct 28, 2005 at 03:56:42AM +0200, Kay Sievers wrote:
Show 8 quoted lines
> 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
Petr Baudis· Nov 1, 2005, 23:30 UTC · re: Chris Shoemaker · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

Dear diary, on Fri, Oct 28, 2005 at 04:38:33AM CEST, I got a letter where Chris Shoemaker <c.shoemaker@cox.net> told me that...

Show 13 quoted lines
> 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· Nov 1, 2005, 23:33 UTC · re: Petr Baudis · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On 11/2/05, Petr Baudis <pasky@suse.cz> 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· Nov 1, 2005, 23:43 UTC · re: Martin Langhoff · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

Dear diary, on Wed, Nov 02, 2005 at 12:33:38AM CET, I got a letter where Martin Langhoff <martin.langhoff@gmail.com> told me that...

Show 6 quoted lines
> On 11/2/05, Petr Baudis <pasky@suse.cz> 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.
Andreas Ericsson· Nov 2, 2005, 08:08 UTC · re: Petr Baudis · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

Petr Baudis wrote:
Show 6 quoted lines
> 
> 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· Nov 2, 2005, 10:37 UTC · re: Andreas Ericsson · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

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· Nov 2, 2005, 12:19 UTC · re: Johannes Schindelin · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

Johannes Schindelin wrote:
Show 12 quoted lines
> 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· Nov 2, 2005, 12:43 UTC · re: Andreas Ericsson · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

Hi,
On Wed, 2 Nov 2005, Andreas Ericsson wrote:
Show 14 quoted lines
> 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

Chris Shoemaker· Nov 2, 2005, 00:12 UTC · re: Martin Langhoff · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:
Show 6 quoted lines
> On 11/2/05, Petr Baudis <pasky@suse.cz> 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· Nov 2, 2005, 00:26 UTC · re: Chris Shoemaker · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On Tue, Nov 01, 2005 at 07:12:06PM -0500, Chris Shoemaker wrote:
Show 11 quoted lines
> On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:
> > On 11/2/05, Petr Baudis <pasky@suse.cz> 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
Petr Baudis· Dec 5, 2005, 00:04 UTC · re: Chris Shoemaker · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

Dear diary, on Wed, Nov 02, 2005 at 01:12:06AM CET, I got a letter where Chris Shoemaker <c.shoemaker@cox.net> said that...

Show 11 quoted lines
> On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:
> > On 11/2/05, Petr Baudis <pasky@suse.cz> 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· Dec 5, 2005, 01:03 UTC · re: Petr Baudis · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

On Mon, Dec 05, 2005 at 01:04:42AM +0100, Petr Baudis wrote:
Show 15 quoted lines
> Dear diary, on Wed, Nov 02, 2005 at 01:12:06AM CET, I got a letter
> where Chris Shoemaker <c.shoemaker@cox.net> said that...
> > On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:
> > > On 11/2/05, Petr Baudis <pasky@suse.cz> 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 <td></td> 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
Josef Weidendorfer· Oct 28, 2005, 09:16 UTC · re: Chris Shoemaker · lore

Re: [PATCH gitweb] Visually indicating patch size with horizontal bars

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

← back to recent threads