[PATCH] gitweb: Do not print "log" and "shortlog" redundantly in commit view

[PATCH] gitweb: Do not print "log" and "shortlog" redundantly in commit view

[Luben Tuikov]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

Do not print "log" and "shortlog" redundantly in commit
view.  This is passed into the $extra argument of
git_print_page_nav from git_commit, but git_print_page_nav
prints "log" and "shortlog" already with the same head.

Noticed by Junio.

Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
 gitweb/gitweb.perl |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

[-- Attachment #2: 1207600725-p1.txt --]
[-- Type: text/plain, Size: 663 bytes --]

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bfd1405..65f1d82 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3014,11 +3014,6 @@ sub git_commit {
 			$cgi->a({-href => href(action=>"blame", hash_parent=>$parent, file_name=>$file_name)},
 			        "blame");
 	}
-	if (defined $co{'parent'}) {
-		push @views_nav,
-			$cgi->a({-href => href(action=>"shortlog", hash=>$hash)}, "shortlog"),
-			$cgi->a({-href => href(action=>"log", hash=>$hash)}, "log");
-	}
 	git_header_html(undef, $expires);
 	git_print_page_nav('commit', defined $co{'parent'} ? '' : 'commitdiff',
 	                   $hash, $co{'tree'}, $hash,
-- 
1.4.2.3.g2e575

Re: [PATCH] gitweb: Do not print "log" and "shortlog" redundantly in commit view

[Jakub Narebski]

Luben Tuikov wrote:

> Do not print "log" and "shortlog" redundantly in commit
> view.  This is passed into the $extra argument of
> git_print_page_nav from git_commit, but git_print_page_nav
> prints "log" and "shortlog" already with the same head.
> 
> Noticed by Junio.
> 
> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>

Gaah, the whole cae1862a3b55b487731e9857f2213ac59d5646d commit
"gitweb: More per-view navigation bar links" is somewhat broken.
Up to this point we used top navigation bar for commit (hash base)
or whole project related links, while bottom part of navigation
bar for "formats" i.e. links related to current view (passing hash)
or for pagination.

So while "snapshot" link has it's place in top navigation bar
(but by modyfying git_print_page_nav subroutine, not by adding it
by hand), "history" for example IMHO doesn't; history link should be
present in the bottom part of navigation bar. Perhaps we could
reuse git_print_page_nav for formats, for example blob wiew would have
        blob | _blame_ | _history_ | _raw_ | _HEAD_
while tree view would have
        tree | _snapshot_ | _history_ | _HEAD_
(where _text_ indices link).  Perhaps _snapshot_ in tree view
shouldn't be repeated, although top one might mean snapshot of commitish,
bottom one snapshot of tree.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] gitweb: Do not print "log" and "shortlog" redundantly in commit view

[Petr Baudis]

Dear diary, on Fri, Oct 06, 2006 at 09:44:29AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Gaah, the whole cae1862a3b55b487731e9857f2213ac59d5646d commit
> "gitweb: More per-view navigation bar links" is somewhat broken.
> Up to this point we used top navigation bar for commit (hash base)
> or whole project related links, while bottom part of navigation
> bar for "formats" i.e. links related to current view (passing hash)
> or for pagination.

Umm, and how did that commit break that? Except the issue this patch
fixes - sorry about that, I have no idea wth was I thinking.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [PATCH] gitweb: Do not print "log" and "shortlog" redundantly in commit view

[Luben Tuikov]

--- Jakub Narebski <jnareb@gmail.com> wrote:
> Gaah, the whole cae1862a3b55b487731e9857f2213ac59d5646d commit
> "gitweb: More per-view navigation bar links" is somewhat broken.
> Up to this point we used top navigation bar for commit (hash base)
> or whole project related links, while bottom part of navigation
> bar for "formats" i.e. links related to current view (passing hash)
> or for pagination.
> 
> So while "snapshot" link has it's place in top navigation bar
> (but by modyfying git_print_page_nav subroutine, not by adding it
> by hand), "history" for example IMHO doesn't; history link should be
> present in the bottom part of navigation bar. Perhaps we could
> reuse git_print_page_nav for formats, for example blob wiew would have
>         blob | _blame_ | _history_ | _raw_ | _HEAD_
> while tree view would have
>         tree | _snapshot_ | _history_ | _HEAD_
> (where _text_ indices link).  Perhaps _snapshot_ in tree view
> shouldn't be repeated, although top one might mean snapshot of commitish,
> bottom one snapshot of tree.

Only a single one: of committish please.

    Luben

Re: [PATCH] gitweb: Do not print "log" and "shortlog" redundantly in commit view

[Petr Baudis]

Dear diary, on Sat, Oct 07, 2006 at 12:16:03AM CEST, I got a letter
where Luben Tuikov <ltuikov@yahoo.com> said that...
> --- Jakub Narebski <jnareb@gmail.com> wrote:
> > Gaah, the whole cae1862a3b55b487731e9857f2213ac59d5646d commit
> > "gitweb: More per-view navigation bar links" is somewhat broken.
> > Up to this point we used top navigation bar for commit (hash base)
> > or whole project related links, while bottom part of navigation
> > bar for "formats" i.e. links related to current view (passing hash)
> > or for pagination.
> > 
> > So while "snapshot" link has it's place in top navigation bar
> > (but by modyfying git_print_page_nav subroutine, not by adding it
> > by hand), "history" for example IMHO doesn't; history link should be
> > present in the bottom part of navigation bar. Perhaps we could
> > reuse git_print_page_nav for formats, for example blob wiew would have
> >         blob | _blame_ | _history_ | _raw_ | _HEAD_
> > while tree view would have
> >         tree | _snapshot_ | _history_ | _HEAD_
> > (where _text_ indices link).  Perhaps _snapshot_ in tree view
> > shouldn't be repeated, although top one might mean snapshot of commitish,
> > bottom one snapshot of tree.
> 
> Only a single one: of committish please.

Then it will be impossible to get snapshot of any subtree (apart of
manually constructing the URL). Hmm, and it's a bug that we don't show
the snapshot link when listing tree entry in tree listing, I thought we
did in the past...?

I think we should make it more clear what each of the bars concerns,
perhaps doing some more significant redesign:

[summary] is redundant, you have this big project name link in the top
left corner. All the other navbar options concern commit, so why not
merge it with the awkward commit box below the navbars?

All the "views bar" options concern the currently selected object, so
why not merge it with the object "descriptor", that is the path?

Patches will follow up.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [PATCH] gitweb: Do not print "log" and "shortlog" redundantly in commit view

[Jakub Narebski]

Petr Baudis wrote:
> Then it will be impossible to get snapshot of any subtree (apart of
> manually constructing the URL). Hmm, and it's a bug that we don't show
> the snapshot link when listing tree entry in tree listing, I thought
> we did in the past...?
> 
> I think we should make it more clear what each of the bars concerns,
> perhaps doing some more significant redesign:
> 
> [summary] is redundant, you have this big project name link in the top
> left corner. All the other navbar options concern commit, so why not
> merge it with the awkward commit box below the navbars?
> 
> All the "views bar" options concern the currently selected object, so
> why not merge it with the object "descriptor", that is the path?
> 
> Patches will follow up.

I think that "summary" has it's place rather in the bottom navigation 
bar, in the "views bar", because it is related to current object not 
current commit (the "tree" entry in top navigation bar, "actions bar", 
is somewhat misleading because it actually is the tree of the commit, 
not any tree). But the refactoring of "views" navigation bar is a good 
idea. For tree it would be
	tree | _history_ | _blame_ | _snapshot_
(when there would be tree_blame back - there was short experiment, patch 
on git list; snapshot of course only when enabled).

I'd leave "summary" view, because the uther, especially with custome 
$home_link_str might be not obvous that it leads to summary view.

-- 
Jakub Narebski
Poland

[PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing

[Petr Baudis]

Currently that's inconsistently reachable only by first displaying the
tree.

Signed-off-by: Petr Baudis <pasky@suse.cz>
---

 gitweb/gitweb.perl |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c4970f4..096a01b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1752,7 +1752,7 @@ sub git_print_simplified_log {
 
 # print tree entry (row of git_tree), but without encompassing <tr> element
 sub git_print_tree_entry {
-	my ($t, $basedir, $hash_base, $have_blame) = @_;
+	my ($t, $basedir, $hash_base, $have_blame, $have_snapshot) = @_;
 
 	my %base_key = ();
 	$base_key{hash_base} = $hash_base if defined $hash_base;
@@ -1798,6 +1798,13 @@ sub git_print_tree_entry {
 			print $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
 			                             file_name=>"$basedir$t->{'name'}")},
 			              "history");
+			if ($have_snapshot) {
+				print " | ";
+			}
+		}
+		if ($have_snapshot) {
+			print $cgi->a({-href => href(action=>"snapshot", hash=>$t->{'hash'})},
+				      "snapshot");
 		}
 		print "</td>\n";
 	}
@@ -2931,7 +2938,7 @@ sub git_tree {
 		}
 		$alternate ^= 1;
 
-		git_print_tree_entry(\%t, $base, $hash_base, $have_blame);
+		git_print_tree_entry(\%t, $base, $hash_base, $have_blame, $have_snapshot);
 
 		print "</tr>\n";
 	}

[PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Petr Baudis]

Signed-off-by: Petr Baudis <pasky@suse.cz>
---

 gitweb/gitweb.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 096a01b..c3d09a2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1791,7 +1791,7 @@ sub git_print_tree_entry {
 		print "<td class=\"list\">";
 		print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
 		                             file_name=>"$basedir$t->{'name'}", %base_key)},
-		              esc_html($t->{'name'}));
+		              esc_html($t->{'name'} . '/'));
 		print "</td>\n";
 		print "<td class=\"link\">";
 		if (defined $hash_base) {

Re: [PATCH] gitweb: Do not print "log" and "shortlog" redundantly in commit view

[Petr Baudis]

Dear diary, on Sat, Oct 07, 2006 at 04:05:22PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
> > Then it will be impossible to get snapshot of any subtree (apart of
> > manually constructing the URL). Hmm, and it's a bug that we don't show
> > the snapshot link when listing tree entry in tree listing, I thought
> > we did in the past...?
> > 
> > I think we should make it more clear what each of the bars concerns,
> > perhaps doing some more significant redesign:
> > 
> > [summary] is redundant, you have this big project name link in the top
> > left corner. All the other navbar options concern commit, so why not
> > merge it with the awkward commit box below the navbars?
> > 
> > All the "views bar" options concern the currently selected object, so
> > why not merge it with the object "descriptor", that is the path?

To make the idea more graphic:

Commit title master             shortlog | log | commit | commitdiff | tree

[project.git] / subdir / filename              blame | history | raw | HEAD


Or perhaps first the navigation, then the title.

> > Patches will follow up.

I have decided to reprioritize and do other stuff now. I will get back
to it sometime later if noone does it first.

> I think that "summary" has it's place rather in the bottom navigation 
> bar, in the "views bar", because it is related to current object not 
> current commit (the "tree" entry in top navigation bar, "actions bar", 
> is somewhat misleading because it actually is the tree of the commit, 
> not any tree).

It's not related to current object any more than to the current commit
and is really out-of-place in both bars. It's related only to the
current project.

We _do_ have a project-global bar at each page. It's the footer,
containing the description and RSS link. What about stashing it there?
;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing

[Luben Tuikov]

--- Petr Baudis <pasky@suse.cz> wrote:
> Currently that's inconsistently reachable only by first displaying the
> tree.

I cannot say that there is any "inconsistency" there per se.  I also
fail to see the value of this patch.

It looks like it just adds interface to gitweb, just because "we can"
and "gitweb can do it".

    Luben

> 
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
> 
>  gitweb/gitweb.perl |   11 +++++++++--
>  1 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index c4970f4..096a01b 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1752,7 +1752,7 @@ sub git_print_simplified_log {
>  
>  # print tree entry (row of git_tree), but without encompassing <tr> element
>  sub git_print_tree_entry {
> -	my ($t, $basedir, $hash_base, $have_blame) = @_;
> +	my ($t, $basedir, $hash_base, $have_blame, $have_snapshot) = @_;
>  
>  	my %base_key = ();
>  	$base_key{hash_base} = $hash_base if defined $hash_base;
> @@ -1798,6 +1798,13 @@ sub git_print_tree_entry {
>  			print $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
>  			                             file_name=>"$basedir$t->{'name'}")},
>  			              "history");
> +			if ($have_snapshot) {
> +				print " | ";
> +			}
> +		}
> +		if ($have_snapshot) {
> +			print $cgi->a({-href => href(action=>"snapshot", hash=>$t->{'hash'})},
> +				      "snapshot");
>  		}
>  		print "</td>\n";
>  	}
> @@ -2931,7 +2938,7 @@ sub git_tree {
>  		}
>  		$alternate ^= 1;
>  
> -		git_print_tree_entry(\%t, $base, $hash_base, $have_blame);
> +		git_print_tree_entry(\%t, $base, $hash_base, $have_blame, $have_snapshot);
>  
>  		print "</tr>\n";
>  	}
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing

[Petr Baudis]

Dear diary, on Sat, Oct 07, 2006 at 08:37:02PM CEST, I got a letter
where Luben Tuikov <ltuikov@yahoo.com> said that...
> --- Petr Baudis <pasky@suse.cz> wrote:
> > Currently that's inconsistently reachable only by first displaying the
> > tree.
> 
> I cannot say that there is any "inconsistency" there per se.  I also
> fail to see the value of this patch.

Currently the bottom navbar is more or less the same as the list of
links in the tree entry (there's the HEAD link but that's a special
case).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Petr Baudis <pasky@suse.cz> wrote:
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---

First, this is a Unixism, and would confuse other OS users.
Second, "/" is after all _not part of the name_ of the tree/directory,
but part of the filesystem's path separator, let's not export it
to users of other OS's.
Third, directories/trees are already clearly 
  1) underlined, and
  2) differently colored,
which makes it overly obvious what it what.

In fact, my eyes only scan for the different color/underlined
entries when I'm searching for a directory in tree view.  I don't even
look at the left-most column.

NACK!

   Luben

> 
>  gitweb/gitweb.perl |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 096a01b..c3d09a2 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1791,7 +1791,7 @@ sub git_print_tree_entry {
>  		print "<td class=\"list\">";
>  		print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
>  		                             file_name=>"$basedir$t->{'name'}", %base_key)},
> -		              esc_html($t->{'name'}));
> +		              esc_html($t->{'name'} . '/'));
>  		print "</td>\n";
>  		print "<td class=\"link\">";
>  		if (defined $hash_base) {
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing

[Luben Tuikov]

--- Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sat, Oct 07, 2006 at 08:37:02PM CEST, I got a letter
> where Luben Tuikov <ltuikov@yahoo.com> said that...
> > --- Petr Baudis <pasky@suse.cz> wrote:
> > > Currently that's inconsistently reachable only by first displaying the
> > > tree.
> > 
> > I cannot say that there is any "inconsistency" there per se.  I also
> > fail to see the value of this patch.
> 
> Currently the bottom navbar is more or less the same as the list of
> links in the tree entry (there's the HEAD link but that's a special
> case).

I completely understand where you're coming from.  I do.

But this patch makes the view so much more cluttered.  And it isn't
vital.  Yes we can do it, yes gitweb can do it, but I doubt the core
value.

Another thing is that currently tree/directory entries' third (links)
column to be shortest of all, and this gives my eyes another indication
that this is a tree.

Imagine a long list of files, and in the middle a directory.  Then
you'd see only the "history" link next to it, as opposed to the long
"history | snapshot"...

I'm ambivalent as to whether this goes in or not.  If the people want it,
so be it.

      Luben


> 
> -- 
> 				Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
> $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jakub Narebski]

Luben Tuikov wrote:

> --- Petr Baudis <pasky@suse.cz> wrote:
>> +                          esc_html($t->{'name'} . '/'));
> 
> First, this is a Unixism, and would confuse other OS users.
But AFAIK _Git_ uses it, in output and in index.

> Second, "/" is after all _not part of the name_ of the tree/directory,
> but part of the filesystem's path separator, let's not export it
> to users of other OS's.
> Third, directories/trees are already clearly 
>   1) underlined, and
>   2) differently colored,
> which makes it overly obvious what it what.
> 
> In fact, my eyes only scan for the different color/underlined
> entries when I'm searching for a directory in tree view.  I don't even
> look at the left-most column.
> 
> NACK!

I'd rather like it.


More important though would be to add better support for symlinks,
perhaps in the UNIX form

        symlink -> _target_

Whete _text_ denotes link.

By the way, I miss somewhat the "redundant" tree/blob links in tree
view...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Petr Baudis]

Dear diary, on Sat, Oct 07, 2006 at 09:06:25PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Luben Tuikov wrote:
> 
> > --- Petr Baudis <pasky@suse.cz> wrote:
> >> +                          esc_html($t->{'name'} . '/'));
> > 
> > First, this is a Unixism, and would confuse other OS users.

drwxr-xr-x

> By the way, I miss somewhat the "redundant" tree/blob links in tree
> view...

I didn't want to post about it but I share the feeling - I have to keep
thinking consciously about clicking on the file name instead of on the
view name - and the situation is worse for regular files, since it is
not really apparent that the filenames are clickablea. My mind knows
that I'm supposed to click on them (not users' mind!), but the eyes and
hands are still clueless.

So, I'd like to either have the view links or the filenames in classical
link style so that it's apparent they are clickable; I didn't post a
patch since I didn't have time/energy to fight for it yet. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing

[Petr Baudis]

Dear diary, on Sat, Oct 07, 2006 at 08:52:53PM CEST, I got a letter
where Luben Tuikov <ltuikov@yahoo.com> said that...
> Another thing is that currently tree/directory entries' third (links)
> column to be shortest of all, and this gives my eyes another indication
> that this is a tree.

What would people think about first listing all the trees, then all the
blobs? Just like LANG=C ls does, as well as cvsweb and overally most of
the rest of the relevant world.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jakub Narebski]

Petr Baudis wrote:

> So, I'd like to either have the view links or the filenames in classical
> link style so that it's apparent they are clickable; I didn't post a
> patch since I didn't have time/energy to fight for it yet. ;-)

There is a tradeout. Either have easily distinguishable directories and
files, by using both different color and decoration (underline), or we have
filename/directory name clearly marked as link. One or the other.

That is why I'd rather have this "redundant" blob/tree link (perhaps in
separate column).

But this is a matter of policy, unless we want to add theme support to
gitweb ;-))
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Petr Baudis]

Dear diary, on Sat, Oct 07, 2006 at 10:38:51PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
> 
> > So, I'd like to either have the view links or the filenames in classical
> > link style so that it's apparent they are clickable; I didn't post a
> > patch since I didn't have time/energy to fight for it yet. ;-)
> 
> There is a tradeout. Either have easily distinguishable directories and
> files, by using both different color and decoration (underline), or we have
> filename/directory name clearly marked as link. One or the other.
> 
> That is why I'd rather have this "redundant" blob/tree link (perhaps in
> separate column).

As I suggested in another mail, perhaps the whole problem is wrong and
you shouldn't have to dug for trees in a bunch of blobs in the first
place - let's group all the trees at the top, as all the well-behaved
directory listings do.

> But this is a matter of policy, unless we want to add theme support to
> gitweb ;-))

We _do_ have that - you can supply your own gitweb.css. But the defaults
should be sensible.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jakub Narebski]

Petr Baudis wrote:

> Dear diary, on Sat, Oct 07, 2006 at 10:38:51PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Petr Baudis wrote:
>> 
>> > So, I'd like to either have the view links or the filenames in classical
>> > link style so that it's apparent they are clickable; I didn't post a
>> > patch since I didn't have time/energy to fight for it yet. ;-)
>> 
>> There is a tradeout. Either have easily distinguishable directories and
>> files, by using both different color and decoration (underline), or we have
>> filename/directory name clearly marked as link. One or the other.
>> 
>> That is why I'd rather have this "redundant" blob/tree link (perhaps in
>> separate column).
> 
> As I suggested in another mail, perhaps the whole problem is wrong and
> you shouldn't have to dug for trees in a bunch of blobs in the first
> place - let's group all the trees at the top, as all the well-behaved
> directory listings do.

It is a good idea, although we would wither to have to read the directory
(tree) listing first into some array, then sort it directories first
(contrary to current output while reading, which reduces latency provided
that browser can properly display partial contents), or add some option
to git-ls-tree command to output tree entries (directories) first, instead
of sorting by filename.

>> But this is a matter of policy, unless we want to add theme support to
>> gitweb ;-))
> 
> We _do_ have that - you can supply your own gitweb.css. But the defaults
> should be sensible.

Theme support, as to be able to choose theme, like style selectable from
web browser, and for example choosing if the tree/blob links are present
or not. Some of which might be done via CSS (display:none).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[A Large Angry SCM]

Luben Tuikov wrote:
> --- Petr Baudis <pasky@suse.cz> wrote:
>> Signed-off-by: Petr Baudis <pasky@suse.cz>
>> ---
> 
> First, this is a Unixism, and would confuse other OS users.
> Second, "/" is after all _not part of the name_ of the tree/directory,
> but part of the filesystem's path separator, let's not export it
> to users of other OS's.
> Third, directories/trees are already clearly 
>   1) underlined, and
>   2) differently colored,
> which makes it overly obvious what it what.
> 
> In fact, my eyes only scan for the different color/underlined
> entries when I'm searching for a directory in tree view.  I don't even
> look at the left-most column.

Not that I care that much, but
   1) not all browsers show underlines (try some text mode browsers)
   2) not all browsers show colors (try some text mode browsers)
   2) not all people see all colors

Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Sat, Oct 07, 2006 at 08:52:53PM CEST, I got a letter
> where Luben Tuikov <ltuikov@yahoo.com> said that...
>> Another thing is that currently tree/directory entries' third (links)
>> column to be shortest of all, and this gives my eyes another indication
>> that this is a tree.
>
> What would people think about first listing all the trees, then all the
> blobs? Just like LANG=C ls does, as well as cvsweb and overally most of
> the rest of the relevant world.

Mildly negative but I do not have strong preference.

BTW, I do not get what you mean by "LANG=C ls".

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> writes:

> --- Petr Baudis <pasky@suse.cz> wrote:
>> Signed-off-by: Petr Baudis <pasky@suse.cz>
>> ---
>
> First, this is a Unixism, and would confuse other OS users.
> Second, "/" is after all _not part of the name_ of the tree/directory,
> but part of the filesystem's path separator, let's not export it
> to users of other OS's.
> Third, directories/trees are already clearly 
>   1) underlined, and
>   2) differently colored,
> which makes it overly obvious what it what.

I was actually hoping that we can get rid of the differences you
cited above.

Underlines make entries harder to read, and colouring is 
distracting; some people do not see all colours and to them it
may not distracting but then they need another way to notice the
differences between tree/blob.

Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing

[Luben Tuikov]

--- Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sat, Oct 07, 2006 at 08:52:53PM CEST, I got a letter
> where Luben Tuikov <ltuikov@yahoo.com> said that...
> > Another thing is that currently tree/directory entries' third (links)
> > column to be shortest of all, and this gives my eyes another indication
> > that this is a tree.
> 
> What would people think about first listing all the trees, then all the
> blobs? Just like LANG=C ls does, as well as cvsweb and overally most of
> the rest of the relevant world.

I don't like it and the reason is that when I'm searching for something
I expect the listing to be alphabetically sorted, period.
Not type-then-alphabetical, which is greatly distracting and only makes
me lose 3-10 seconds looking for the item I'm looking at.

Bunching up the directories at the top and then listing the files at
the bottom is one of those great annoyances.

But, if you do implement that, please make it configurable, because
I'll resort to the current listing order.

    Luben

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > --- Petr Baudis <pasky@suse.cz> wrote:
> >> Signed-off-by: Petr Baudis <pasky@suse.cz>
> >> ---
> >
> > First, this is a Unixism, and would confuse other OS users.
> > Second, "/" is after all _not part of the name_ of the tree/directory,
> > but part of the filesystem's path separator, let's not export it
> > to users of other OS's.
> > Third, directories/trees are already clearly 
> >   1) underlined, and
> >   2) differently colored,
> > which makes it overly obvious what it what.
> 
> I was actually hoping that we can get rid of the differences you
> cited above.
> 
> Underlines make entries harder to read, and colouring is 
> distracting; some people do not see all colours and to them it
> may not distracting but then they need another way to notice the
> differences between tree/blob.

I know, I've seen your email on that and have your patch with the
icons applied at work.  But it is black and white and I'd rather
see some nice color and shading if we're going to change that.

I don't mind using nice warm color icons in the left-most column.

   Luben

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Petr Baudis]

> Dear diary, on Sat, Oct 07, 2006 at 09:06:25PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
> > By the way, I miss somewhat the "redundant" tree/blob links in tree
> > view...
> 
> I didn't want to post about it but I share the feeling - I have to keep
> thinking consciously about clicking on the file name instead of on the
> view name - and the situation is worse for regular files, since it is
> not really apparent that the filenames are clickablea. My mind knows
> that I'm supposed to click on them (not users' mind!), but the eyes and
> hands are still clueless.

I was looking into accesslogs of repo.or.cz for something and noticed
that I see unusually large number of blame requests. That of course
attracted my curiosity and I came to conclusion that what I'm seeing is
not just my personal whim but we have serious usability problem here.

I'm unfortunately not sure when the update of repo.or.cz gitweb which
dropped the blob/tree links happenned, so the following _is_ somewhat
dubious, but I think it's quite telling anyway.

I have three samples (logfiles) available: #2 almost certainly when the
blob link was still there, #1 covering the switch and some time before
and after, and #0 certainly when the blob link was not there anymore,
but unfortunately spanning only one or two days.

This is the count of actions invoked from the tree, commit and
commitdiff view (using the referer information):

    blame  blob   total requests containing 'a='
#2  1      18     264
#1  31     23     399
#0  4      6      50

The disparation between #2 and #1,#0 is quite apparent. If we want more
exact results, I will let #0 accumulate data for a week and then revert
the removal of the links and start another sample.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> This is the count of actions invoked from the tree, commit and
> commitdiff view (using the referer information):
>
>     blame  blob   total requests containing 'a='
> #2  1      18     264
> #1  31     23     399
> #0  4      6      50
>
> The disparation between #2 and #1,#0 is quite apparent. If we want more
> exact results, I will let #0 accumulate data for a week and then revert
> the removal of the links and start another sample.

I am not sure -- you are certainly counting me looking at your
blame output while working on the slimmed down blame output (you
may remember that I noted that while your output gives names and
dates for each line which is busier I kind of liked it in one of
my previous messages), and we talked about gitweb blame lot
recently on the list so that might have spurred people's
curiosity.

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Petr Baudis <pasky@suse.cz> writes:
>
>> This is the count of actions invoked from the tree, commit and
>> commitdiff view (using the referer information):
>>
>>     blame  blob   total requests containing 'a='
>> #2  1      18     264
>> #1  31     23     399
>> #0  4      6      50
>>
>> The disparation between #2 and #1,#0 is quite apparent. If we want more
>> exact results, I will let #0 accumulate data for a week and then revert
>> the removal of the links and start another sample.
>
> I am not sure -- you are certainly counting me looking at your
> blame output while working on the slimmed down blame output (you
> may remember that I noted that while your output gives names and
> dates for each line which is busier I kind of liked it in one of
> my previous messages), and we talked about gitweb blame lot
> recently on the list so that might have spurred people's
> curiosity.

Having said that, I agree to the point you are trying to make
here.  It was a mistake to remove blob/tree links from the view
that lists pathnames.

If we did not have any obviously clickable links on the right
hand side it might have been a different story, but when given
UNIXy permission bits, pathname and blame/history/raw links,
nobody would think of clicking on the pathname itself to grab
its contents.  The blame link would give you the same
information (and a bit more) and people would just go there
without much thinking.

It probably is wise to resurrect those "redundant" links.

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:
> Having said that, I agree to the point you are trying to make
> here.  It was a mistake to remove blob/tree links from the view
> that lists pathnames.
> 
> If we did not have any obviously clickable links on the right
> hand side it might have been a different story, but when given
> UNIXy permission bits, pathname and blame/history/raw links,
> nobody would think of clicking on the pathname itself to grab
> its contents.  The blame link would give you the same

I've seen the exact opposite.

BTW, what is our standard here? People with zero-computer
exposure? With some? With high?

Certainly, if I didn't know what a folder/directory/tree is,
and what a file is and I was told to "get" that file, the first
thing I'd do when I see it on the screen would be to "put my pointer
over the file and press the action button".

It is when people actually start to "think" is when they fail
to naively click on the pathname (name of the file) to get it.

The naive approach is to simply click on what you want to get.

The interesting point here is that people with zero and high
computer exposure tend to click on the file name to obtain it.
Only people with some computer exposure start to "think" and
"figure it out" and fail to intuit to naively point at the
file name to get the file. 

So this is 2/3 to 1/3.

> information (and a bit more) and people would just go there
> without much thinking.
> 
> It probably is wise to resurrect those "redundant" links.

If someone does this, can they also remove the now "other"
redundant link? (the link at the pathname itself) A simple
code analyzer would show the duplicate code in gitweb.

   Luben

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> writes:

> --- Junio C Hamano <junkio@cox.net> wrote:
>> Having said that, I agree to the point you are trying to make
>> here.  It was a mistake to remove blob/tree links from the view
>> that lists pathnames.
>> 
>> If we did not have any obviously clickable links on the right
>> hand side it might have been a different story, but when given
>> UNIXy permission bits, pathname and blame/history/raw links,
>> nobody would think of clicking on the pathname itself to grab
>> its contents.  The blame link would give you the same
>
> I've seen the exact opposite.
>
> BTW, what is our standard here? People with zero-computer
> exposure? With some? With high?
>
> Certainly, if I didn't know what a folder/directory/tree is,
> and what a file is and I was told to "get" that file, the first
> thing I'd do when I see it on the screen would be to "put my pointer
> over the file and press the action button".

I would agree with that if we did not have anything on the right
hand side that attracts eye and hand to tempt clicking.  And
that would be true for all levels of users.

If we replaced UNIXy mode bits with folder/file/symlink icons,
people might be tempted to click on them as well.

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jeff King]

On Mon, Oct 09, 2006 at 10:38:41PM -0700, Luben Tuikov wrote:

> The interesting point here is that people with zero and high
> computer exposure tend to click on the file name to obtain it.
> Only people with some computer exposure start to "think" and
> "figure it out" and fail to intuit to naively point at the
> file name to get the file. 
> 
> So this is 2/3 to 1/3.

2/3 to 1/3 if you're counting categories, but you haven't presented any
evidence that the number of people in each category is the same.

Besides which, I think that people with a high degree of exposure to the
web tend to look for the things that look like buttons or links. The
near-universal sign for links on the web is underlining (and typically
an alternate color). Looking at the repo.or.cz file lists, I see that
none of the files is highlighted but the directories are. What am I to
guess (either by intuition or by "figuring it out") except that there is
some difference between clicking the two? I think we are failing a
consistency test.

-Peff

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Petr Baudis <pasky@suse.cz> wrote:
> I was looking into accesslogs of repo.or.cz for something and noticed
> that I see unusually large number of blame requests. That of course
> attracted my curiosity and I came to conclusion that what I'm seeing is
> not just my personal whim but we have serious usability problem here.
> 
> I'm unfortunately not sure when the update of repo.or.cz gitweb which
> dropped the blob/tree links happenned, so the following _is_ somewhat
> dubious, but I think it's quite telling anyway.
> 
> I have three samples (logfiles) available: #2 almost certainly when the
> blob link was still there, #1 covering the switch and some time before
> and after, and #0 certainly when the blob link was not there anymore,
> but unfortunately spanning only one or two days.
> 
> This is the count of actions invoked from the tree, commit and
> commitdiff view (using the referer information):
> 
>     blame  blob   total requests containing 'a='
> #2  1      18     264
> #1  31     23     399
> #0  4      6      50
> 
> The disparation between #2 and #1,#0 is quite apparent. If we want more
> exact results, I will let #0 accumulate data for a week and then revert
> the removal of the links and start another sample.

Oh, my, oh, my.

Anyone can come up with any "statistic" to convince anyone of
anything.  It's the American way! (to financial success)

I mean, I can even give you a mathematical series which I can add
in certain orders to give me any number I want...  Which is not at
all intutitive.

Anyway, the "confused" link clearly says "blame".  I'm not sure why
your people were trying to think and figure it out, as opposed to
simply clicking on the file name itself.  It is the most intuitive
thing to do as I mentioned in my previous email.

Did you do any demographics on your clickers?  What is their background?
Did you try to calculate how statistically correct your sample is
and if the clickers represent the general computer population out there?
What is your sampling error?

I can hardly accept this "statistic" as a proof to "reintroduce
the redundant links".

But I give up.

If you guys want the redundant links back in, so be it -- submit
a patch.

Then let's fortify gitweb, because we can.  Lets add links and more
redundancy to fortify the user interface so that all and any possibilities
are covered.  And as soon as a NEW git facility is introduced, then
we'll add 10 or 20 more links to gitweb for this just one, single
new facility.  Then with each new single facility if it is related to
any other, the number of links would grow exponentially.  Then after
such and such time has passed, let's look at the code.  Then let's
ask if someone has left maintaining the then gitweb jungle.  More
importantly, let's ask if someone has left _using_ it.  (That would
be the ripe time to start afresh with gitweb2.perl.)

As long as job is being done and the patches are flowing in, and
more and more code is introduced, albeit redundantly, we shouldn't
care what the people who use this every day want or care for.

Hey, let's add more links!

     Luben
P.S. I'll go and collect some statistics now.

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:
> I would agree with that if we did not have anything on the right
> hand side that attracts eye and hand to tempt clicking.  And
> that would be true for all levels of users.
> 
> If we replaced UNIXy mode bits with folder/file/symlink icons,
> people might be tempted to click on them as well.

Then they should probably "get" the jpg/png image of the icon, ;-)
each time they click on it.  If they really wanted the file, then
they should probably just simply click on the file name.

    Luben

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Jeff King <peff@peff.net> wrote:
> 2/3 to 1/3 if you're counting categories, but you haven't presented any
> evidence that the number of people in each category is the same.
> 
> Besides which, I think that people with a high degree of exposure to the
> web tend to look for the things that look like buttons or links. The
> near-universal sign for links on the web is underlining (and typically

Then let's universally underline absolutely _every_ link in gitweb
which is clickable, regardless of where it appears, the font, typeset
and size.

Who will be my hero and submit that patch?  I'll surely commit it
and make the people happy.

> an alternate color). Looking at the repo.or.cz file lists, I see that
> none of the files is highlighted but the directories are. What am I to
> guess (either by intuition or by "figuring it out") except that there is
> some difference between clicking the two? I think we are failing a
> consistency test.

Let's see:

Each line which starts with a "d" also has some kind of underlined
text in the second column.

Each line which starts with a "-" has text which is not underlined
in the second column.

Which implies a connection between the "d" and the property of
underlining.

Unless you have "a priori" knowlege of "underline means clickable" there
is no chance of thinking that "not-underlined means not-clickable".

   Luben

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jeff King]

On Mon, Oct 09, 2006 at 11:41:17PM -0700, Luben Tuikov wrote:

> Then let's universally underline absolutely _every_ link in gitweb
> which is clickable, regardless of where it appears, the font, typeset
> and size.

Instead, let's make a strawman argument!

Though I agree that it would be nicer for ALL links in gitweb to be
consistent, I think there is an argument to be made about look. However,
the specific example I mentioned is a single list in which some elements
are underlined and blue (which has been the classic user interface hint
for a link for a decade), and some aren't. Do you see why I think that
might be inconsistent?

> Unless you have "a priori" knowlege of "underline means clickable" there

Which was my argument in the first place (note that I was talking about
people with a high degree of computer exposure).

> is no chance of thinking that "not-underlined means not-clickable".

There is clearly a non-zero chance. Here's a relatively ridiculous
argument.

Look at the 'summary' page for a project. For each commit, there are
blue and underlined 'commitdiff', 'text', and 'snapshot' links.  The
date, author, and message text have no such decoration. I click on the
underlined things and see that they are all links. I click on date and
author and see they are not links. The pattern of underlining links has
held for five out of six elements. Do you think it's unreasonable to
guess that the sixth element is not a link based on that pattern?


Look, I agree that not underlining everything might make the page look
nicer. And if we want to balance consistency against aesthetics, that's
fine. But please don't argue that there isn't an inconsistency.

-Peff

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jeff King]

On Mon, Oct 09, 2006 at 11:21:26PM -0700, Luben Tuikov wrote:

> Anyone can come up with any "statistic" to convince anyone of
> anything.  It's the American way! (to financial success)

Petr introduced quantitative evidence and an analysis. You can argue
that his numbers or his analysis are incorrect, but berating statistics
as a whole is not a compelling argument.

> Anyway, the "confused" link clearly says "blame".  I'm not sure why
> your people were trying to think and figure it out, as opposed to
> simply clicking on the file name itself.  It is the most intuitive
> thing to do as I mentioned in my previous email.

Is it? I think the point of Petr's data is to show that, for whatever
reason, people are NOT intuitively doing as you expect.

> Did you do any demographics on your clickers?  What is their background?

Aren't they, by definition, gitweb users? And isn't that the target
demographic?  You can argue that there are potential gitweb users who
will behave completely differently, but I haven't seen any evidence to
support that claim.

> I can hardly accept this "statistic" as a proof to "reintroduce
> the redundant links".

It's not a proof. It's evidence in support of a claim. Sorry, but this
isn't math.

-Peff

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Andreas Ericsson]

This discussion has taken a wrong turn and ended up somewhere in the 
murky backwaters of questionable sanity.

I like my links blue and underlined. Can't be arsed to mouse over things 
to figure out if they're clickable. If they're not blue and underlined, 
they're not, insofar as I'm concerned.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Mon, Oct 09, 2006 at 11:21:26PM -0700, Luben Tuikov wrote:
>
>> Anyone can come up with any "statistic" to convince anyone of
>> anything.  It's the American way! (to financial success)
>
> Petr introduced quantitative evidence and an analysis. You can argue
> that his numbers or his analysis are incorrect, but berating statistics
> as a whole is not a compelling argument.

Although I tend to agree with Pasky, I think Luben has a point
in that the click count he quoted does not have enough samples
and also tainted by known skews (both Gitzilla and I have
admitted that we hit blames unnecessarily not because we wanted
to see the blamed project but because we wanted to see how the
blame on his site shows things) to draw any meaningful
conclusion.

But that is as far as I would go agreeing with Luben on this
thread.  If we did not have anything else that obviously are
clickable it might be natural to expect people to click on
otherwise unhighlighted filenames to grab the blob data.  But
the current layout that shows filenames in plain and a few
obviously clickable links on the same line draws eyes and mouse
away from the filename and to the links on the right hand side,
even for somebody like me, who intellectually knows (because I
merged it) that the filenames in trees ought to be clickable.

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jakub Narebski]

Luben Tuikov wrote:

>> It probably is wise to resurrect those "redundant" links.
> 
> If someone does this, can they also remove the now "other"
> redundant link? (the link at the pathname itself) A simple
> code analyzer would show the duplicate code in gitweb.

Easy, easy now.


I'd rather add some more "hidden" links, but for each hidden
link (which are convenience only, to have larger are to click,
or to have closer area to click) I'd like to have clearly marked
link (marked as a link, i.e. using default link style; and with link text
denoting _kind_ of link) which leads to the same contents. 

For example on project list page I would made also project description
(and not only project name) clickable, leading tp project summary.
Making project name direct link wouldn't work for sites like kernel.org
with long (hierarchical) project names like
  linux/kernel/git/wim/linux-2.6-watchdog-experimental.git
And for other sites project name is/can be bit on the short side.

But we agreed (I guess) to disagree on the whole redundancy in user
interface issue (although I agree on the issue of reducing clutter).
BTW. we can reduce redundancy in the code without need for removing
"alternate entry points" in interface, I think.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Josef Weidendorfer]

On Tuesday 10 October 2006 10:07, Andreas Ericsson wrote:
> I like my links blue and underlined. Can't be arsed to mouse over things 
> to figure out if they're clickable. If they're not blue and underlined, 
> they're not, insofar as I'm concerned.

Same opinion here.

Better be functional than beautiful but confusing.

If Gitweb would be a desktop application, we would have context menues
for different actions on list items, but that is not really possible
with web pages (?), and would be unexpected.

Gitweb is a web interface. So lets use the conventions for web pages.
One solution is to repeat the actions everytime in every row of a list,
as we do now (and I think is fine; we could use icons instead). The other
standard solution is to have checkboxes at the front of every row, and
the actions as buttons, which means two mouse clicks (which IMHO is a
really bad UI).

And as we go with the first solution, we explicitly should state all
possible actions, and not provide an hidden action which is triggered
when clicking on the entry name. Currently, it is not very clear that
* we have a "blob" action at all,
* clicking on the entry name provides the blob action. Seems to me
like an arbitrary choice. Why not "raw" or "blame" instead?
Therefore, I am in favor of reintroducing the "blob" link,
which allows the entry names to stay as they are
now (and could get the hidden redundant action).

One thing I found confusing in this regard the first time:
Why do list rows show a recoloring with mouse over?
This somehow suggest that the whole row makes up some kind of
a button and is clickable (BTW, blame pages do not do this).
Can we get rid of this?

Josef

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> One thing I found confusing in this regard the first time:
> Why do list rows show a recoloring with mouse over?

It's a highlight and it's a good highlight.  It suggests that the
row is "alive", i.e. that the title is clickable.  It "shows" you
your current "selection" by having the mouse pointer over the row.

I like it.

    Luben

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Tuesday 10 October 2006 10:07, Andreas Ericsson wrote:
> > I like my links blue and underlined. Can't be arsed to mouse over things 
> > to figure out if they're clickable. If they're not blue and underlined, 
> > they're not, insofar as I'm concerned.
> 
> Same opinion here.
> 
> Better be functional than beautiful but confusing.

Indeed.

The larger the group of people deciding on an issue, the less
forward ideas and thinking is introduced.  They are inversely
proportional.

Note that almost all forward ideas and ground breaking thoughts have
always been introduced by one, at most two people, not in a forum
or committee.  For example (relavant to the audience of this list):
Linux, git, sparse.

Imagine if the design of git has been initiated in a committee or
a mailing list or a forum...

Can someone please submit those two patches
  a) one which underlines ALL clickable links in ALL of gitweb, and
  b) second which puts redundant links of everything to everything,
     just because we can,
and then we can move on?

Thanks,
    Luben

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Josef Weidendorfer]

On Tuesday 10 October 2006 20:23, Luben Tuikov wrote:
> --- Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > One thing I found confusing in this regard the first time:
> > Why do list rows show a recoloring with mouse over?
> 
> It's a highlight and it's a good highlight.  It suggests that the
> row is "alive", i.e. that the title is clickable.

If you look e.g. at a gitweb shortlog, neither the first nor the
second column is clickable. Still, there is this highlighting.
I remember I clicked and wondered that nothing is happening.

> It "shows" you 
> your current "selection" by having the mouse pointer over the row.

As you can do nothing with this "selection", it really makes no
sense to show it. If you could make this selection permanent by
clicking on the row, and do some actions on your selection,
it would be different.

IMHO, a valid argument would be that this highlighting makes it
easier to quickly see which information in different columns belong
together, especially when much whitespace is used.
But for this, alternative coloring of rows is enough.

Josef

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Jakub Narebski <jnareb@gmail.com> wrote:
> Luben Tuikov wrote:
> 
> >> It probably is wise to resurrect those "redundant" links.
> > 
> > If someone does this, can they also remove the now "other"
> > redundant link? (the link at the pathname itself) A simple
> > code analyzer would show the duplicate code in gitweb.
> 
> Easy, easy now.

Can you please CC me when replying to a post of mine?  Else
I have to go chase in the git folder as opposed it coming to
my inbox.  Thanks!

> I'd rather add some more "hidden" links, but for each hidden
> link (which are convenience only, to have larger are to click,
> or to have closer area to click) I'd like to have clearly marked
> link (marked as a link, i.e. using default link style; and with link text
> denoting _kind_ of link) which leads to the same contents. 

Why would you like all this?  If users start using those other links
all the time, what is the purpose of the "hidden" links as you call them?

Consider the "tree" link between "commitdiff" and "snapshot" (if enabled)
in shortlog view.

Consider the "hidden" link of each entry (file/directory).

Can you see how they are different?

Introducing this to an engineer who has little knowlege about git:
   "Click on the file or directory name, to get the file or go into
    the directory"
Simple and intuitive, no need to mention "blob" or "tree" or "object".
Or,
   "Click on the 'blob' link to get the ... Click on the 'tree' link to
    get the ... Oh you didn't know what a 'tree' or 'blob' object is?
    A 'blob' is ... A 'tree' is ..."

At which point the engineer has lost 90% of his interest.

It even gets even worse for the obnoxious "tree" link next to each commit
in shortlog view:
   "The tree link is the the tree object which is part of a commit object.
    Oh you don't know the internals of a commit object?  A commit object
    binds a tree object and a (parent) commit object, but blah, blah, blah..."

Can you see how all this apparent "simplicity" you're trying to introduce
contradics the mere links you're introducing it with?

Surely "we can", but should we?  The "tree" link in shortlog next to each commit
is one such example of "we can", but we shouldn't.

The question is: Given the average engineer, what is the gitweb interface
such that they can start using it fastest with the minimum amount of
questions?

> But we agreed (I guess) to disagree on the whole redundancy in user
> interface issue (although I agree on the issue of reducing clutter).
> BTW. we can reduce redundancy in the code without need for removing
> "alternate entry points" in interface, I think.

Clutter and redundancy is just a part of it.  A larger part is
how much git or non-git oriented we want to make the interface, which
seems related to the overall simplicity and intuitiveness.

The golden question:
What is the interface such that both git-experts and never-seen-git-
but-know-about-SCMs engineers can find it intuitive to use with minimal
amount of questions?

    Luben

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> writes:

> Or,
>    "Click on the 'blob' link to get the ... Click on the 'tree' link to
>     get the ... Oh you didn't know what a 'tree' or 'blob' object is?
>     A 'blob' is ... A 'tree' is ..."
>
> At which point the engineer has lost 90% of his interest.
>
> It even gets even worse for the obnoxious "tree" link next to each commit
> in shortlog view:
>    "The tree link is the the tree object which is part of a commit object.
>     Oh you don't know the internals of a commit object?  A commit object
>     binds a tree object and a (parent) commit object, but blah, blah, blah..."

Isn't that a simple "labelling" question?  I do not think
anybody minds to show clickable string "contents" (instead of
"blob" or "tree") at the places you mention above and if we did
so everybody would be happy, right?

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jakub Narebski]

Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
>> Luben Tuikov wrote:
>> 
>>>> It probably is wise to resurrect those "redundant" links.
>>> 
>>> If someone does this, can they also remove the now "other"
>>> redundant link? (the link at the pathname itself) A simple
>>> code analyzer would show the duplicate code in gitweb.
>>
>> I'd rather add some more "hidden" links, but for each hidden
>> link (which are convenience only, to have larger are to click,
>> or to have closer area to click) I'd like to have clearly marked
>> link (marked as a link, i.e. using default link style; and with
>> link text denoting _kind_ of link) which leads to the same contents. 
> 
> Why would you like all this?  If users start using those other links
> all the time, what is the purpose of the "hidden" links as you call
> them? 

It was answered in the part you haven't quoted. Sometimes "hidden link" 
purpose it is to have larger area where we can click, for example in 
"tree" view the name of file (the name of directory is not hidden, as
it uses default link style), in "shortlog"/"heads"/"tags" view the title
(subject) of a commit/ref. Sometimes it is to have link closer, for
example name of files in diff header being "hidden link" to file 
contents before and after the change.

"Hidden links" are in fact half hidden, as I think all of them are 
underlined on mouseover. 

But, as I have said, we cannot use default link style for those "hidden 
links", either because as in "shortlog" view this would negatively 
affect readibility, or it would clash with syntax highlighting as in 
the case of "commitdiff" and "blobdiff" views, or because we have two 
types of object we want to be visually distinct, but there is only one 
default style of links like in the case of directory (tree) and file 
(blob) entries in the "tree" view.
 
> Consider the "tree" link between "commitdiff" and "snapshot" 
> (if enabled) in shortlog view.
> 
> Consider the "hidden" link of each entry (file/directory).
> 
> Can you see how they are different?

Yes, "tree" link is small, blue (if not visited), and underlined.
But I guess that wasn't what you had in mind.

IMPORTANT: By the way, by removing 'redundant' "blob"/"tree" link we 
remove the possibility of denoting which links (which directories and 
files) we have visited (sic!).

> Introducing this to an engineer who has little knowlege about git:
>    "Click on the file or directory name, to get the file or go into
>     the directory"
> Simple and intuitive, no need to mention "blob" or "tree" or "object".
> Or,
>    "Click on the 'blob' link to get the ... Click on the 'tree' link
>    to get the ... Oh you didn't know what a 'tree' or 'blob' object
>    is? A 'blob' is ... A 'tree' is ..."
>
> At which point the engineer has lost 90% of his interest.

The links are for git and gitweb users. They tell (we assume that git 
user knows what blob, tree, etc. means; we assume that gitweb user 
knows what blob views or tree view means)
    "Click on the 'blob' link to get 'blob' view for current line file"
like the "history" link tells
    "Click on the 'history' link to get history of a current line file"

For example "hidden link" of title/subject of a commit in "shortlog" or 
"history" view doesn't tell us what kind of view it leads too: commit, 
commitdiff? Well, it doesn't tell us that it is link, either... ;-)

> It even gets even worse for the obnoxious "tree" link next to each
> commit in shortlog view:
>    "The tree link is the the tree object which is part of a commit
>     object. Oh you don't know the internals of a commit object?
>     A commit object binds a tree object and a (parent) commit object,
>     but blah, blah, blah..." 
> 
> Can you see how all this apparent "simplicity" you're trying to
> introduce contradics the mere links you're introducing it with?

I don't understand you. The "tree" link in shortlog is a _shortcut_ to 
the "tree" view (and I think that one can guess that tree view means 
directory listing in the state as saved by given commit), without it 
you would have to do it in two steps, first going to commit view, then 
clicking on tree in the main navbar. So it is IMHO usefull.

Perhaps you meant "tree" header in "commit" view? There surely we could 
use ordinary link style for sha1 which is tree identifier. Cause surely 
we don't need for the sha1 to be readable, as in the case of commit 
title in the shortlog view. Additionally it would serve as a way to 
distinguish on first glance which headers are clickable, and which are 
not. And there we could I guess loose redundant headers.

[...]

> The question is: Given the average engineer, what is the gitweb
> interface such that they can start using it fastest with the minimum
> amount of  questions?

Given average user/programmer... 

>> But we agreed (I guess) to disagree on the whole redundancy in user
>> interface issue (although I agree on the issue of reducing clutter).
>> BTW. we can reduce redundancy in the code without need for removing
>> "alternate entry points" in interface, I think.
> 
> Clutter and redundancy is just a part of it.  A larger part is
> how much git or non-git oriented we want to make the interface, which
> seems related to the overall simplicity and intuitiveness.

One must pay atention to not to make interface _too simple_, and less 
usable because of it. And definition of intuitiveness depends on the 
person...

-- 
Jakub Narebski
Poland

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jakub Narebski]

Junio C Hamano wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > Or,
> >    "Click on the 'blob' link to get the ... Click on the 'tree' link to
> >     get the ... Oh you didn't know what a 'tree' or 'blob' object is?
> >     A 'blob' is ... A 'tree' is ..."
> >
> > At which point the engineer has lost 90% of his interest.
> >
> > It even gets even worse for the obnoxious "tree" link next to each commit
> > in shortlog view:
> >    "The tree link is the the tree object which is part of a commit object.
> >     Oh you don't know the internals of a commit object?  A commit object
> >     binds a tree object and a (parent) commit object, but blah, blah, blah..."
> 
> Isn't that a simple "labelling" question?  I do not think
> anybody minds to show clickable string "contents" (instead of
> "blob" or "tree") at the places you mention above and if we did
> so everybody would be happy, right?

Not, IMHO it is not a good idea. Clicking on file name leads to it
contents, but it is not obvoius what kind of view is it. "blob" link
leads to blob view, "tree" link leads to tree view, which are known
what they mean to any git user.
-- 
Jakub Narebski
Poland

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > Or,
> >    "Click on the 'blob' link to get the ... Click on the 'tree' link to
> >     get the ... Oh you didn't know what a 'tree' or 'blob' object is?
> >     A 'blob' is ... A 'tree' is ..."
> >
> > At which point the engineer has lost 90% of his interest.
> >
> > It even gets even worse for the obnoxious "tree" link next to each commit
> > in shortlog view:
> >    "The tree link is the the tree object which is part of a commit object.
> >     Oh you don't know the internals of a commit object?  A commit object
> >     binds a tree object and a (parent) commit object, but blah, blah, blah..."
> 
> Isn't that a simple "labelling" question?  I do not think

Not quite.  You have to explain to the engineer that the "tree" link
next to each "comit title" "shows" the project _at the state of that
commit_.  Which is the WORST PR for git and gitweb.  Why?

Because now you have to explain internals of git and gitweb.

Instead of letting the engineer click on the commit to see the commit
and then the commit provides a _context_ where "tree" makes much more
intuitive sense.

OTOH, if one is an expert in git, then they have no problem
getting to the information: commit->tree.

> anybody minds to show clickable string "contents" (instead of
> "blob" or "tree") at the places you mention above and if we did

Well, "contents" of a commit is a tricky thing.  This is why I don't
like the "tree" link next to each commit in shortlog, but didn't mention
anything when the patch was posted a couple of days ago.

It is just an unnecessary "fast forward interpretation" of commit.

> so everybody would be happy, right?

I don't know anymore.

    Luben
P.S. Notice how there is a "snapshot" link on each line of
shortlog, but there is no "snapshot" link in the nav bar
of a=commit.  The "snapshot" link is next to "tree" down
in the commit data.  There is also a "tree" link which is also
in the navbar, but "shortlog" is missing.

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jakub Narebski]

Luben Tuikov wrote:
> P.S. Notice how there is a "snapshot" link on each line of
> shortlog, but there is no "snapshot" link in the nav bar
> of a=commit.  The "snapshot" link is next to "tree" down
> in the commit data.  There is also a "tree" link which is also
> in the navbar, but "shortlog" is missing.

The problem with snapshot is that we can have snapshot of a commit
(and all links in the top part of navigation bar till now deals with 
current commit), and snapshot of a tree, which can be subdirectory
(and all links in the bottom part of navigation bar deals with 
the views/presentations of a current object).
-- 
Jakub Narebski
Poland

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> > 
> > > Or,
> > >    "Click on the 'blob' link to get the ... Click on the 'tree' link to
> > >     get the ... Oh you didn't know what a 'tree' or 'blob' object is?
> > >     A 'blob' is ... A 'tree' is ..."
> > >
> > > At which point the engineer has lost 90% of his interest.
> > >
> > > It even gets even worse for the obnoxious "tree" link next to each commit
> > > in shortlog view:
> > >    "The tree link is the the tree object which is part of a commit object.
> > >     Oh you don't know the internals of a commit object?  A commit object
> > >     binds a tree object and a (parent) commit object, but blah, blah, blah..."
> > 
> > Isn't that a simple "labelling" question?  I do not think
> > anybody minds to show clickable string "contents" (instead of
> > "blob" or "tree") at the places you mention above and if we did
> > so everybody would be happy, right?
> 
> Not, IMHO it is not a good idea. Clicking on file name leads to it
> contents, but it is not obvoius what kind of view is it. "blob" link

It is pretty obvious to me: the contents of the object, whether it be
"blob" or "tree".  The contents of "blob" and the contents of "tree"
as shown by gitweb.

   Luben


> leads to blob view, "tree" link leads to tree view, which are known
> what they mean to any git user.
> -- 
> Jakub Narebski
> Poland
> 

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jakub Narebski]

Dnia wtorek 10. października 2006 23:02, Luben Tuikov napisał:
> > > Isn't that a simple "labelling" question?  I do not think
> > > anybody minds to show clickable string "contents" (instead of
> > > "blob" or "tree") at the places you mention above and if we did
> > > so everybody would be happy, right?
> > 
> > Not, IMHO it is not a good idea. Clicking on file name leads to it
> > contents, but it is not obvoius what kind of view is it. "blob" link
> 
> It is pretty obvious to me: the contents of the object, whether it be
> "blob" or "tree".  The contents of "blob" and the contents of "tree"
> as shown by gitweb.

It's pretty obvous to you, because there is only one basic view of tree, 
and one basic view of blob. It is not the case for example for commits 
in shortlog view, where we have commit and commitdiff views. It is 
possible that either blobs or trees acquire another views.
-- 
Jakub Narebski
Poland

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Jakub Narebski <jnareb@gmail.com> wrote:
> Luben Tuikov wrote:
> > P.S. Notice how there is a "snapshot" link on each line of
> > shortlog, but there is no "snapshot" link in the nav bar
> > of a=commit. �The "snapshot" link is next to "tree" down
> > in the commit data. �There is also a "tree" link which is also
> > in the navbar, but "shortlog" is missing.
> 
> The problem with snapshot is that we can have snapshot of a commit
> (and all links in the top part of navigation bar till now deals with 
> current commit), and snapshot of a tree, which can be subdirectory
> (and all links in the bottom part of navigation bar deals with 
> the views/presentations of a current object).

Oh, yes, that's exactly what we need: two links of the same name
("snapshot") in the top row of navbar and in the bottom row of navbar.

     Luben

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Luben Tuikov]

--- Jakub Narebski <jnareb@gmail.com> wrote:
> Dnia wtorek 10. pa�dziernika 2006 23:02, Luben Tuikov napisa�:
> > > > Isn't that a simple "labelling" question? �I do not think
> > > > anybody minds to show clickable string "contents" (instead of
> > > > "blob" or "tree") at the places you mention above and if we did
> > > > so everybody would be happy, right?
> > > 
> > > Not, IMHO it is not a good idea. Clicking on file name leads to it
> > > contents, but it is not obvoius what kind of view is it. "blob" link
> > 
> > It is pretty obvious to me: the contents of the object, whether it be
> > "blob" or "tree". �The contents of "blob" and the contents of "tree"
> > as shown by gitweb.
> 
> It's pretty obvous to you, because there is only one basic view of tree, 
> and one basic view of blob. It is not the case for example for commits 
> in shortlog view, where we have commit and commitdiff views. It is 
> possible that either blobs or trees acquire another views.

Excuse me, weren't we talking about "blob" and "tree"?

How come you all of a sudden introduce commits?  Let's keep on topic:
"blob" and "tree".

   Luben

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Jakub Narebski]

Dnia środa 11. października 2006 00:14, Luben Tuikov napisał:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
> > Luben Tuikov wrote:
> > > P.S. Notice how there is a "snapshot" link on each line of
> > > shortlog, but there is no "snapshot" link in the nav bar
> > > of a=commit. The "snapshot" link is next to "tree" down
> > > in the commit data. There is also a "tree" link which is also
> > > in the navbar, but "shortlog" is missing.
> > 
> > The problem with snapshot is that we can have snapshot of a commit
> > (and all links in the top part of navigation bar till now deals with 
> > current commit), and snapshot of a tree, which can be subdirectory
> > (and all links in the bottom part of navigation bar deals with 
> > the views/presentations of a current object).
> 
> Oh, yes, that's exactly what we need: two links of the same name
> ("snapshot") in the top row of navbar and in the bottom row of navbar.

I'm mentioning the problem, that "snapshot" has two meaning for a tree.
I personally think that we should have commit snapshot links (with 
commit sha in the extended tar header if we use tgz snapshots) for 
"heads", "tags" and "project list" views, and perhaps in the "commit" 
and optionally "commitdiff" view; perhaps but not necessary for each 
commit-list view like log, shortlog, search, history. But the snapshot 
link should be as a view of a (sub)directory only in the bottom part of 
navigation bar.

-- 
Jakub Narebski
Poland

Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing

[Andreas Ericsson]

Luben Tuikov wrote:
> 
> The question is: Given the average engineer, what is the gitweb interface
> such that they can start using it fastest with the minimum amount of
> questions?
> 

Originally, the question was about average gitweb users. I'm sorry 
Luben, but as long as you propagate links that are not
a) blue
b) underlined
I'll have to disagree with everything you say out of pure principle.

> 
> The golden question:
> What is the interface such that both git-experts and never-seen-git-
> but-know-about-SCMs engineers can find it intuitive to use with minimal
> amount of questions?
> 

Just make links blue and underlined and people will click them out of 
curiousity. 100% guaranteed. Try to spoonfeed engineers and they will 
spit on you, because engineers like to figure things out, even if 
they're obvious. Try to make things intuitive for average users and you 
will be wrong, because intuition is highly culture- and experience 
oriented. Try to make it foolproof and you will fail, because fools are 
so ingenious.

The one and only thing everyone looking at a gitweb interface has in 
common is curiousity, so appeal to that rather than trying any of the 
doomed paths above.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231