[PATCH] gitweb: tree view: eliminate redundant "blob"

[PATCH] gitweb: tree view: eliminate redundant "blob"

[Luben Tuikov]

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

Binary and non-binary blobs:

The "list" table element of tree view is identical
to the "blob" link part of the link table element.
I.e. clicking on "blob" is identical to clicking on
the entry itself.

Thus, eliminate "blob" from being shown -- the user
can get identical result by simply clicking on the
entry itself.

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 1207600725-p1.txt --]
[-- Type: text/inline; name="p1.txt", Size: 2304 bytes --]

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 66be619..c7ab3b6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1600,34 +1600,35 @@ sub git_print_tree_entry {
 	my %base_key = ();
 	$base_key{hash_base} = $hash_base if defined $hash_base;
 
+	# The format of a table row is: mode list link.  Where mode is
+	# the mode of the entry, list is the name of the entry, an href,
+	# and link is the action links of the entry.
+
 	print "<td class=\"mode\">" . mode_str($t->{'mode'}) . "</td>\n";
 	if ($t->{'type'} eq "blob") {
 		print "<td class=\"list\">" .
-		      $cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
-		                             file_name=>"$basedir$t->{'name'}", %base_key),
-		              -class => "list"}, esc_html($t->{'name'})) .
-		      "</td>\n" .
-		      "<td class=\"link\">" .
-		      $cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
-		                             file_name=>"$basedir$t->{'name'}", %base_key)},
-		              "blob");
+			$cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
+					       file_name=>"$basedir$t->{'name'}", %base_key),
+				 -class => "list"}, esc_html($t->{'name'})) . "</td>\n";
+		print "<td class=\"link\">";
 		if ($have_blame) {
-			print " | " .
-				$cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
-				                       file_name=>"$basedir$t->{'name'}", %base_key)},
-				        "blame");
+			print $cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
+						     file_name=>"$basedir$t->{'name'}", %base_key)},
+				      "blame");
 		}
 		if (defined $hash_base) {
-			print " | " .
-			      $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
+			if ($have_blame) {
+				print " | ";
+			}
+			print $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
 			                             hash=>$t->{'hash'}, file_name=>"$basedir$t->{'name'}")},
 			              "history");
 		}
 		print " | " .
 		      $cgi->a({-href => href(action=>"blob_plain",
 		                             hash=>$t->{'hash'}, file_name=>"$basedir$t->{'name'}")},
-		              "raw") .
-		      "</td>\n";
+		              "raw");
+		print "</td>\n";
 
 	} elsif ($t->{'type'} eq "tree") {
 		print "<td class=\"list\">" .
-- 
1.4.2.1.gdbbb

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> writes:

> Binary and non-binary blobs:
>
> The "list" table element of tree view is identical
> to the "blob" link part of the link table element.
> I.e. clicking on "blob" is identical to clicking on
> the entry itself.

Then perhaps we can lose tree link for the same reasoning?

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > Binary and non-binary blobs:
> >
> > The "list" table element of tree view is identical
> > to the "blob" link part of the link table element.
> > I.e. clicking on "blob" is identical to clicking on
> > the entry itself.
> 
> Then perhaps we can lose tree link for the same reasoning?

Indeed, I think so too.

    Luben

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

Luben Tuikov wrote:

> Binary and non-binary blobs:
> 
> The "list" table element of tree view is identical
> to the "blob" link part of the link table element.
> I.e. clicking on "blob" is identical to clicking on
> the entry itself.
> 
> Thus, eliminate "blob" from being shown -- the user
> can get identical result by simply clicking on the
> entry itself.

I'd rather not. The fact that the file name and tree name is link,
and the fact that commit title and tag title is link is a _convenience_.
Not always it is visible (without mouseover) that it is link.
And it is _not_ visible in the case of files!

And for example for commits and heads there are two possible
views, commit and commitdiff for commit, shortlog and log for head,
of which we arbitrary chose one for the subject link. So in that
case the additional self link is needed. I'd rather have both.
And for consistency I'd rather always have visible form default
self link/

I'd rather have additional link, than cause confusion to the users.
Perhaps we could separate the self link ("blob" for files, "tree"
for directories) into separate column?

Besides, you have to mouse over the name of file, or name of
directory to see to what view it would lead on.

Nak.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

Jakub Narebski wrote:

> Nak.

Gaaah. I can see that it is applied in next. I'd rather it would not.

Redundancy is sometimes good.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Petr Baudis]

Dear diary, on Tue, Sep 26, 2006 at 10:54:49AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> I'd rather not. The fact that the file name and tree name is link,
> and the fact that commit title and tag title is link is a _convenience_.
> Not always it is visible (without mouseover) that it is link.
> And it is _not_ visible in the case of files!

Then that should be fixed.

And directories should have trailing slash in their name in the tree
listing, for people with non-UNIX background who don't understand the
ls -l like output.

> And for example for commits and heads there are two possible
> views, commit and commitdiff for commit, shortlog and log for head,
> of which we arbitrary chose one for the subject link. So in that
> case the additional self link is needed. I'd rather have both.

For commits and heads, I agree. But that's not what this patch does.

> And for consistency I'd rather always have visible form default
> self link/

A parse error kicked me off here, sorry.


(I'm personally kind of ambivalent to the change.)

-- 
				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: tree view: eliminate redundant "blob"

[Jakub Narebski]

Petr Baudis wrote:

> Dear diary, on Tue, Sep 26, 2006 at 10:54:49AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> I'd rather not. The fact that the file name and tree name is link,
>> and the fact that commit title and tag title is link is a _convenience_.
>> Not always it is visible (without mouseover) that it is link.
>> And it is _not_ visible in the case of files!
> 
> Then that should be fixed.
> 
> And directories should have trailing slash in their name in the tree
> listing, for people with non-UNIX background who don't understand the
> ls -l like output.

Something like ls -lF format? Currently directories differs visibly
from file entries, because directory entries are visibly links. One
single slash at the end is much less visible than change of color and
underline.

Besides "blob" link for files and "tree" link for directories states
explicitely the kind of view. List entry link states this implicitely.
I'd rather like the redundancy.

>> And for example for commits and heads there are two possible
>> views, commit and commitdiff for commit, shortlog and log for head,
>> of which we arbitrary chose one for the subject link. So in that
>> case the additional self link is needed. I'd rather have both.
> 
> For commits and heads, I agree. But that's not what this patch does.

What this patch does is introduce inconsistency. Even if you agree
to treat commits and heads specially, it treats directory entries
differently from file entries; and differently from tag entries
(where tag objects have the same duplication) in tags view. In tags
view on one hand it clearly distiguish lightweight from "heavyweight"
tags (even heavyweight tags without tag message), on the other
"tag | tag ..." for tag pointing to tag is quite strange.
 
>> And for consistency I'd rather always have visible form default
>> self link/
> 
> A parse error kicked me off here, sorry.
 
I'd rather always have the link which is in "list" entry stated
also explicitely.
 
> (I'm personally kind of ambivalent to the change.)

There are many other changes which should be rather done, like for
example remotes/ support.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Luben Tuikov]

--- Petr Baudis <pasky@suse.cz> wrote:
> And directories should have trailing slash in their name in the tree
> listing, for people with non-UNIX background who don't understand the
> ls -l like output.

In the non-UNIX environment, there is "folders", not "directories".
Also, in the non-UNIX environment, the path separator is '\'.

The point is that it is not unreasonable to draw the line somewhere.

A 'd' at the front of directories is easy enough to understand,
plus the fact that directory entries are underlined and blue, wlg.

   Luben

> 
> > And for example for commits and heads there are two possible
> > views, commit and commitdiff for commit, shortlog and log for head,
> > of which we arbitrary chose one for the subject link. So in that
> > case the additional self link is needed. I'd rather have both.
> 
> For commits and heads, I agree. But that's not what this patch does.
> 
> > And for consistency I'd rather always have visible form default
> > self link/
> 
> A parse error kicked me off here, sorry.
> 
> 
> (I'm personally kind of ambivalent to the change.)
> 
> -- 
> 				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] gitweb: tree view: eliminate redundant "blob"

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Tue, Sep 26, 2006 at 10:54:49AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> I'd rather not. The fact that the file name and tree name is link,
>> and the fact that commit title and tag title is link is a _convenience_.
>> Not always it is visible (without mouseover) that it is link.
>> And it is _not_ visible in the case of files!
>
> Then that should be fixed.
>
> And directories should have trailing slash in their name in the tree
> listing, for people with non-UNIX background who don't understand the
> ls -l like output.

I am with you on both counts.  For the latter, people might
actually like mode string to be changed to pretty pictures,
though.

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

Junio C Hamano wrote:

> Petr Baudis <pasky@suse.cz> writes:
> 
>> Dear diary, on Tue, Sep 26, 2006 at 10:54:49AM CEST, I got a letter
>> where Jakub Narebski <jnareb@gmail.com> said that...
>>> I'd rather not. The fact that the file name and tree name is link,
>>> and the fact that commit title and tag title is link is a _convenience_.
>>> Not always it is visible (without mouseover) that it is link.
>>> And it is _not_ visible in the case of files!
>>
>> Then that should be fixed.
>>
>> And directories should have trailing slash in their name in the tree
>> listing, for people with non-UNIX background who don't understand the
>> ls -l like output.
> 
> I am with you on both counts.  For the latter, people might
> actually like mode string to be changed to pretty pictures,
> though.

And perhaps we could also use yet another decoration for symbolic links.
Perhaps different color? Perhaps 'ls -l' view, i.e. 'link -> target'? 

But if we use different colors for tree entries and blob entries (and
perhaps yet another color for symbolic links), it is impossible to mark all
of them clearly as links. So I'd rather have redundancy, than hidden
functionality (BTW. I hate MS idea of vanishing menu entries based on
usage).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Luben Tuikov]

--- Jakub Narebski <jnareb@gmail.com> wrote:
> I'd rather not. The fact that the file name and tree name is link,
> and the fact that commit title and tag title is link is a _convenience_.
> Not always it is visible (without mouseover) that it is link.
> And it is _not_ visible in the case of files!
> 
> And for example for commits and heads there are two possible
> views, commit and commitdiff for commit, shortlog and log for head,
> of which we arbitrary chose one for the subject link. So in that
> case the additional self link is needed. I'd rather have both.
> And for consistency I'd rather always have visible form default
> self link/
> 
> I'd rather have additional link, than cause confusion to the users.
> Perhaps we could separate the self link ("blob" for files, "tree"
> for directories) into separate column?
> 
> Besides, you have to mouse over the name of file, or name of
> directory to see to what view it would lead on.

Jakub,

I understand your argument completely.  Underlining/coloring/etc
entities which are "links" themselves was very cool circa 1993 when
I took an HTML course (NSA Mosaic or rather...), transitioning from
"gopher" to the WWW.

Over the years I've seen a transition where web content is more and
more context sensitive, i.e. everything you can see is in some way
"clickable".  Be it letters, words, sentences, graphical objects of
some sort, etc.  If you could imagine: any web content being a "wiki
on steroids".

Generally, this WEB Development argument goes as follows:
    "There is no reason for anything to not be clickable."

Thus, I like the fact that gitweb is on the forefront of WEB development.
We should keep it like that.

    Luben

> 
> Nak.
> -- 
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
> 
> 
> -
> 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] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

Luben Tuikov wrote:

> Jakub,
> 
> I understand your argument completely.  Underlining/coloring/etc
> entities which are "links" themselves was very cool circa 1993 when
> I took an HTML course (NSA Mosaic or rather...), transitioning from
> "gopher" to the WWW.
> 
> Over the years I've seen a transition where web content is more and
> more context sensitive, i.e. everything you can see is in some way
> "clickable".  Be it letters, words, sentences, graphical objects of
> some sort, etc.  If you could imagine: any web content being a "wiki
> on steroids".
>
> Generally, this WEB Development argument goes as follows:
>     "There is no reason for anything to not be clickable."
> 
> Thus, I like the fact that gitweb is on the forefront of WEB development.
> We should keep it like that.

This is example of where forefront has it wrong. I'm all for "list" entry
to be link to default view, but I'm all against removing clearly marked
link to "plain"/"tree" view.

And "invisible links" _especially_ if the link is not convenience only
(i.e. it is not provided clearly as link somewhere else) is so called
"mystery meat navigation" and is one of the most common mistakes in
web development.

And is not as if "plain |" takes much space...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Luben Tuikov]

--- Jakub Narebski <jnareb@gmail.com> wrote:
> This is example of where forefront has it wrong. I'm all for "list" entry
> to be link to default view, but I'm all against removing clearly marked
> link to "plain"/"tree" view.
> 
> And "invisible links" _especially_ if the link is not convenience only
> (i.e. it is not provided clearly as link somewhere else) is so called
> "mystery meat navigation" and is one of the most common mistakes in
> web development.
> 
> And is not as if "plain |" takes much space...

I think you would agree that gitweb is quite different than what is
commonly defined as "mystery meat navigation".

Gitweb is very well thought out interface, and self-contained.
There isn't much pondering about what and where to click, have newbies
too.

Think about the removal of the redundant "blob" and "tree" as database
schema normalization if you will.  The redundancy is so well defined that
even applying a simple algorithm to gitweb.perl will discover it.

Either that or you can think of it as "shortening" the line.
Wlg, suppose that I have a file called "blob" and a directory
called "tree":
    mode blob    blob | blame | history | raw
    mode tree    tree | history
Is equivalent to
    mode blob    blame | history | raw
    mode tree    history
For any name "blob" and any name "tree".

Plus the code (gitweb.perl) has less redundancy and overhead.

     Luben

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

Luben Tuikov wrote:

> --- Jakub Narebski <jnareb@gmail.com> wrote:
>> This is example of where forefront has it wrong. I'm all for "list" entry
>> to be link to default view, but I'm all against removing clearly marked
>> link to "plain"/"tree" view.
>> 
>> And "invisible links" _especially_ if the link is not convenience only
>> (i.e. it is not provided clearly as link somewhere else) is so called
>> "mystery meat navigation" and is one of the most common mistakes in
>> web development.
>> 
>> And is not as if "blob |" takes much space...
> 
> I think you would agree that gitweb is quite different than what is
> commonly defined as "mystery meat navigation".

If you need to mouseover to discover that a part of webpage is link, it is
mystery meat navigation. Not in it's worst kind (it is quite obvious on
mouseover that that part is link), but still.

> Gitweb is very well thought out interface, and self-contained.
> There isn't much pondering about what and where to click, have newbies
> too.

But some links are hidden. But there is always (or should be always)
visible, i.e. in default link colors (blue for unvisited), and default
decoration (underline not only on mouseover - that's mystery meat
navigation).

> Think about the removal of the redundant "blob" and "tree" as database
> schema normalization if you will.  The redundancy is so well defined that
> even applying a simple algorithm to gitweb.perl will discover it.

Redundancy is not always bad. Especially in interface.

> Either that or you can think of it as "shortening" the line.
> Wlg, suppose that I have a file called "blobname" and a directory
> called "treename":
>     mode blobname    blob | blame | history | raw
>     mode treename    tree | history
> Is equivalent to
>     mode blobname    blame | history | raw
>     mode treename    history
> For any name "blob" and any name "tree".

But then we _must_ (to not have mystery meat navigation) mark "blobname"
and "treename" _clearly_ as links, while using different visual (e.g.
different colors) to clearly distinguish between "blob" entry and "tree"
entry. And no, mode and remaining links (well, "raw") is not enough.
Which is somewhat contradictory. And makes interface somewhat inconsistent
(although removing both "blob" link for blobs and "tree" link for trees is
a step towards consistency).

> Plus the code (gitweb.perl) has less redundancy and overhead.

Redundancy in _interface_ is not always bad. We have a lot of redundancy
(mostly via hidden _convenience_ links) in gitweb interface.

Overhead? What overhead? Creating the page? It's negligible. Size of the
page? It is small enough for current net bandwidths; creation time is
bottleneck (not for "tree" view though), not the bandwidth.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

Jakub Narebski wrote:

> But some links are hidden. But there is always (or should be always)
> visible, i.e. in default link colors (blue for unvisited), and default
> decoration (underline not only on mouseover - that's mystery meat
> navigation)...

...link that is equivalent to the "invisible" link.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> writes:

>> And "invisible links" _especially_ if the link is not convenience only
>> (i.e. it is not provided clearly as link somewhere else) is so called
>> "mystery meat navigation" and is one of the most common mistakes in
>> web development.
>> 
>> And is not as if "plain |" takes much space...
>
> I think you would agree that gitweb is quite different than what is
> commonly defined as "mystery meat navigation".
>
> Gitweb is very well thought out interface, and self-contained.
> There isn't much pondering about what and where to click, have newbies
> too.
>
> Think about the removal of the redundant "blob" and "tree" as database
> schema normalization if you will.
>...
> Either that or you can think of it as "shortening" the line.

Very well put.  I think this and removal of redundant "tree"
would be worthy changes -- it unclutters things.

If the only objection is that it is harder to realize that the
remaining one (the other one that did not get removed by this
redundancy elimination) is clickable, maybe that is what needs
to be fixed.

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

On Wed, 27 Sep 2006, Junio C Hamano wrote:
> If the only objection is that it is harder to realize that the
> remaining one (the other one that did not get removed by this
> redundancy elimination) is clickable, maybe that is what needs
> to be fixed.

But that is plain impossible without compromising interface usability.
Let me explain. 

In the case of tree view (directory listing) we have blobs (files and 
symlinks) and trees (directories). To mark item unequivocably as link 
it has to have default link color (blue) and default link decoration 
(underline). That means that we cannot distinguish really well (at 
least color) between tree and blob entries. I'd rather have redundant 
"blob"/"tree" (self)links, clearly marked as links, and tree entries 
using link decoration (blue, underlined) while blob entries have 
default text decoration (black, no underline).

In the case of shortlog/log/history/heads/tags view, to clearly mark 
subject/title of a commit or tag as link, we would have to use default 
link decoration. Let's for a while abandon link-within-link, i.e. using 
some of committags also in commit title (in shortlog/history view)...
But underlined text is harder to read, and blue underlined text even 
more so (as for example it is hard to read italics, commonly used for 
emphasis). I'd rather have additional "commit" link, clearly marked as 
link, and leave subject as is, as hidden link, as a shortcut.

I think that redundancy in a visual interface (and not only visual, as 
seen in the example of Perl programming language) is a good idea, 
contrary to the redundancy in code or data (database).
-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> ... That means that we cannot distinguish really well (at 
> least color) between tree and blob entries.

Do we even say links are blue and underlined by forcing that in
our css?

Doesn't leading drwxr-xr-x mean anything?

Why is making the distinction important in the first place?

> In the case of shortlog/log/history/heads/tags view, to clearly mark 
> subject/title of a commit or tag as link, we would have to use default 
> link decoration....
> But underlined text is harder to read, and blue underlined text even 
> more so...

This is something in which I can see some more sense than tree
vs blob issue, but only as a principle issue.  In practice, the
list of commit subjects is the first thing users encounter, and
as long as there is some visual indication (e.g. mousing over it
makes it obvious it is something that is clickable), I think
users will quickly pick up that it will lead to the commit's
detail.

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > ... That means that we cannot distinguish really well (at 
> > least color) between tree and blob entries.
> 
> Do we even say links are blue and underlined by forcing that in
> our css?

That is default style of link element, as specified by default CSS
for HTML/XHTML.

> Doesn't leading drwxr-xr-x mean anything?

Neither d in drwxr-xr-x, nor trailing / in the name are significant
enough indicators of directory vs file (tree vs blob) indicator,
especially that by default git-ls-tree output mixes trees with blobs.
 
> Why is making the distinction important in the first place?

If you browse tree, you usually click on tree links, but not on blob
links.

> > In the case of shortlog/log/history/heads/tags view, to clearly mark 
> > subject/title of a commit or tag as link, we would have to use default 
> > link decoration....
> > But underlined text is harder to read, and blue underlined text even 
> > more so...
> 
> This is something in which I can see some more sense than tree
> vs blob issue, but only as a principle issue.  In practice, the
> list of commit subjects is the first thing users encounter, and
> as long as there is some visual indication (e.g. mousing over it
> makes it obvious it is something that is clickable), I think
> users will quickly pick up that it will lead to the commit's
> detail.

Well, that is certainly the question of style (redundancy vs. uncluttered
output plus some coding issues).

By the way, I've planned to move printing those kind of links to separate
subroutine (output based on type of object the links are related to, and
somewhat als on the action/view we are in)...
-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Andreas Ericsson]

Jakub Narebski wrote:
> Junio C Hamano wrote:
> 
>> Doesn't leading drwxr-xr-x mean anything?
> 
> Neither d in drwxr-xr-x, nor trailing / in the name are significant
> enough indicators of directory vs file (tree vs blob) indicator,
> especially that by default git-ls-tree output mixes trees with blobs.
>  

I beg to differ. The trailing slash would indeed help, as peoples eyes 
are generally focused on the mouse-pointer rather than some 5-10" to the 
left of it. If we're worrying that windows folks use \ for 
path-delimiter, I think they'll pick up the difference quick enough.

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

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

Andreas Ericsson wrote:
> Jakub Narebski wrote:
>> Junio C Hamano wrote:
>> 
>>> Doesn't leading drwxr-xr-x mean anything?
>> 
>> Neither d in drwxr-xr-x, nor trailing / in the name are significant
>> enough indicators of directory vs file (tree vs blob) indicator,
>> especially that by default git-ls-tree output mixes trees with blobs.
>>  
> 
> I beg to differ. The trailing slash would indeed help, as peoples eyes 
> are generally focused on the mouse-pointer rather than some 5-10" to the 
> left of it. If we're worrying that windows folks use \ for 
> path-delimiter, I think they'll pick up the difference quick enough.

I agree that it would help, but it is not enough when tree (directory)
and blob (file) would have the same color and the same decoration.

-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Junio C Hamano]

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

> Jakub Narebski <jnareb@gmail.com> writes:
>
>> ... That means that we cannot distinguish really well (at 
>> least color) between tree and blob entries.
>
> Do we even say links are blue and underlined by forcing that in
> our css?
>
> Doesn't leading drwxr-xr-x mean anything?
>
> Why is making the distinction important in the first place?

Anyhow, I was too tired to sleep after an unscheduled day-job on
Sunday X-<, and whipped this up for fun.

-- >8 --
[PATCH] gitweb: remove UNIXy mode bits from tree display

and replace it with an image icon for cuteness ;-).

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 gitweb/gitweb.css  |   20 ++++++++++++++++++++
 gitweb/gitweb.perl |   21 ++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletions(-)

diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index eb9fc38..c4aaf7c 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -211,6 +211,26 @@ td.selflink {
 	padding-right: 0px;
 }
 
+td.executable {
+  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAACVJREFUCNdjYGBgYGdgMEhgUFBgYGJgcBKAIiAbKAIUB8oyMAAANBcCqbivEbgAAAAASUVORK5CYII=);
+  background-repeat: no-repeat;
+}
+
+td.folder {
+  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAAB1JREFUCNdjYGBgkGFgUGJgcPzA4CCABdV/ACoBAFTTBQ822ZerAAAAAElFTkSuQmCC);
+  background-repeat: no-repeat;
+}
+
+td.regular {
+  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAABtJREFUCNdjqD/A4JDA4BDA4FDB4MCBHdX/AACO5wbfUNnbqwAAAABJRU5ErkJggg==);
+  background-repeat: no-repeat;
+}
+
+td.symlink {
+  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAACVJREFUCNdjYGBg4G9gMEhgUFBgcBAAIQYYYlFg4ElgkG8AKgEARSsDX750+Y0AAAAASUVORK5CYII=);
+  background-repeat: no-repeat;
+}
+
 td.sha1 {
 	font-family: monospace;
 }
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7e4ec8d..8c54a5d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -567,6 +567,23 @@ sub age_string {
 }
 
 # convert file mode in octal to symbolic file mode string
+sub kind_class {
+	my ($type, $mode) = @_;
+	$mode = oct $mode;
+	if (S_ISDIR($mode & S_IFMT)) {
+		return 'folder';
+	} elsif (S_ISLNK($mode)) {
+		return 'symlink';
+	} elsif (S_ISREG($mode)) {
+		# git cares only about the executable bit
+		if ($mode & S_IXUSR) {
+			return 'executable';
+		} else {
+			return 'regular';
+		};
+	}
+}
+
 sub mode_str {
 	my $mode = oct shift;
 
@@ -1651,7 +1668,9 @@ sub git_print_tree_entry {
 	# the mode of the entry, list is the name of the entry, an href,
 	# and link is the action links of the entry.
 
-	print "<td class=\"mode\">" . mode_str($t->{'mode'}) . "</td>\n";
+	my $kind = kind_class($t->{'type'}, $t->{'mode'});
+	print "<td class=\"$kind\">&nbsp;</td>\n";
+
 	if ($t->{'type'} eq "blob") {
 		print "<td class=\"list\">" .
 			$cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
-- 
1.4.2.2.g91c5

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> 
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> ... That means that we cannot distinguish really well (at 
>>> least color) between tree and blob entries.
>>
>> Do we even say links are blue and underlined by forcing that in
>> our css?
>>
>> Doesn't leading drwxr-xr-x mean anything?
>>
>> Why is making the distinction important in the first place?
> 
> Anyhow, I was too tired to sleep after an unscheduled day-job on
> Sunday X-<, and whipped this up for fun.
> 
> -- >8 --
> [PATCH] gitweb: remove UNIXy mode bits from tree display
> 
> and replace it with an image icon for cuteness ;-).

[...]
> +td.executable {
> +  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAACVJREFUCNdjYGBgYGdgMEhgUFBgYGJgcBKAIiAbKAIUB8oyMAAANBcCqbivEbgAAAAASUVORK5CYII=);
> +  background-repeat: no-repeat;
> +}
> +
> +td.folder {
> +  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAAB1JREFUCNdjYGBgkGFgUGJgcPzA4CCABdV/ACoBAFTTBQ822ZerAAAAAElFTkSuQmCC);
> +  background-repeat: no-repeat;
> +}
> +
> +td.regular {
> +  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAABtJREFUCNdjqD/A4JDA4BDA4FDB4MCBHdX/AACO5wbfUNnbqwAAAABJRU5ErkJggg==);
> +  background-repeat: no-repeat;
> +}
> +
> +td.symlink {
> +  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAACVJREFUCNdjYGBg4G9gMEhgUFBgcBAAIQYYYlFg4ElgkG8AKgEARSsDX750+Y0AAAAASUVORK5CYII=);
> +  background-repeat: no-repeat;
> +}
> +

Wouldn't it be better to use out-of-line images? I'm not sure if all browsers
support CSS embedded images, and if all browsers can cache such images.

Perhaps we could reuse Apache's MultiView/index.html.var... err, gitweb
tries to be web server agnostic...

And what about text browsers? It would be better to use <img> element, with
alt attribute set either to old UNIX-y mode bits, and title set to the file
type... or perhaps both alt and title attributes set to file type.

>  # convert file mode in octal to symbolic file mode string
> +sub kind_class {
> +	my ($type, $mode) = @_;
> +	$mode = oct $mode;
> +	if (S_ISDIR($mode & S_IFMT)) {
> +		return 'folder';
> +	} elsif (S_ISLNK($mode)) {
> +		return 'symlink';
> +	} elsif (S_ISREG($mode)) {
> +		# git cares only about the executable bit
> +		if ($mode & S_IXUSR) {
> +			return 'executable';
> +		} else {
> +			return 'regular';
> +		};
> +	}
> +}
> +

We have file_type subroutine, which does almost the same work. It doesn't
mark file as "executable", and it uses "directory" instead of non-standard
"folder".

By the way, $type argument (parameter) is not used at all.

> @@ -1651,7 +1668,9 @@ sub git_print_tree_entry {
>  	# the mode of the entry, list is the name of the entry, an href,
>  	# and link is the action links of the entry.
>  
> -	print "<td class=\"mode\">" . mode_str($t->{'mode'}) . "</td>\n";
> +	my $kind = kind_class($t->{'type'}, $t->{'mode'});
> +	print "<td class=\"$kind\">&nbsp;</td>\n";
> +
>  	if ($t->{'type'} eq "blob") {
>  		print "<td class=\"list\">" .
>  			$cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},

-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > ... That means that we cannot distinguish really well (at 
> > least color) between tree and blob entries.
> 
> Do we even say links are blue and underlined by forcing that in
> our css?
> 
> Doesn't leading drwxr-xr-x mean anything?
> 
> Why is making the distinction important in the first place?
> 
> > In the case of shortlog/log/history/heads/tags view, to clearly mark 
> > subject/title of a commit or tag as link, we would have to use default 
> > link decoration....
> > But underlined text is harder to read, and blue underlined text even 
> > more so...
> 
> This is something in which I can see some more sense than tree
> vs blob issue, but only as a principle issue.  In practice, the
> list of commit subjects is the first thing users encounter, and
> as long as there is some visual indication (e.g. mousing over it
> makes it obvious it is something that is clickable), I think
> users will quickly pick up that it will lead to the commit's
> detail.

Very well put.

   Luben

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Luben Tuikov]

--- Jakub Narebski <jnareb@gmail.com> wrote:
> But that is plain impossible without compromising interface usability.
> Let me explain. 
> 
> In the case of tree view (directory listing) we have blobs (files and 
> symlinks) and trees (directories). To mark item unequivocably as link 
> it has to have default link color (blue) and default link decoration 
> (underline). That means that we cannot distinguish really well (at 
> least color) between tree and blob entries. I'd rather have redundant 
> "blob"/"tree" (self)links, clearly marked as links, and tree entries 
> using link decoration (blue, underlined) while blob entries have 
> default text decoration (black, no underline).
> 
> In the case of shortlog/log/history/heads/tags view, to clearly mark 
> subject/title of a commit or tag as link, we would have to use default 
> link decoration. Let's for a while abandon link-within-link, i.e. using 
> some of committags also in commit title (in shortlog/history view)...
> But underlined text is harder to read, and blue underlined text even 
> more so (as for example it is hard to read italics, commonly used for 
> emphasis). I'd rather have additional "commit" link, clearly marked as 
> link, and leave subject as is, as hidden link, as a shortcut.
> 
> I think that redundancy in a visual interface (and not only visual, as 
> seen in the example of Perl programming language) is a good idea, 
> contrary to the redundancy in code or data (database).

Jakub,

Your opinion here is highly subjective.

Years of experience make certain things "make sense" and other
"make less sense".  Note that that is in itself subjective.

Give it 10 years, your opinion will change.

     Luben

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
>> I think that redundancy in a visual interface (and not only visual, as 
>> seen in the example of Perl programming language) is a good idea, 
>> contrary to the redundancy in code or data (database).
> 
> Jakub,
> 
> Your opinion here is highly subjective.

Yours too.
 
> Years of experience make certain things "make sense" and other
> "make less sense".  Note that that is in itself subjective.
> 
> Give it 10 years, your opinion will change.

Perhaps. Perhaps not.

I guess we have to agree to disagree. It's Junio opinion that
matters (which patches would get accepted).

I'd like to mention that there are if I remember correctly
some other places, like "commit" view which have this hated by
you redundancy.
-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Luben Tuikov wrote:
>> --- Jakub Narebski <jnareb@gmail.com> wrote:
>>> I think that redundancy in a visual interface (and not only visual, as 
>>> seen in the example of Perl programming language) is a good idea, 
>>> contrary to the redundancy in code or data (database).
>> 
>> Jakub,
>> 
>> Your opinion here is highly subjective.
>
> Yours too.
>  
>> Years of experience make certain things "make sense" and other
>> "make less sense".  Note that that is in itself subjective.
>> 
>> Give it 10 years, your opinion will change.
>
> Perhaps. Perhaps not.
>
> I guess we have to agree to disagree. It's Junio opinion that
> matters (which patches would get accepted).

Honestly, I _hate_ to be in the position to decide in which
color the bikeshed should be, but sometimes that is what a
maintainer has to do.

I personally feel that in a list that is one line per item, like
the shortlog, we do not necessarily have to underline the log
message even though they are clickable.  The purpose of the list
is to show things so people can read them.  Readability matters.
At the same time we would want to give access to object details;
I think it is Ok not to give underline to them, as long as
people can easily pick up the convention that each of these
listed items is clickable to obtain details about it.  We should
probably make other clickable links at the right, such as "tree"
and "snapshot", visually stand out, by giving underline as we
already do.  They are not really "text", but clickable icons
that happen to be done with text (as opposed to being done with
img).

By the same logic, the purpose of the tree view is to show
contents of a tree object.  If the user picks up the convention
for the short log that each listed commit can be clicked to
obtain details about it, it probably is natural for the user to
expect that each listed entry in the tree view can be clicked to
obtain details about it, so not showing the redundant tree/blob
link is in line with that.  And it would be consistent not to
give underline to the file or directory names.

By the way, you are right in saying if we were to do icons they
should be out-of-line img with help for text browsers.  That
patch was done as illustration not as a serious patch (I am not
a serious gitweb hacker, so anything I do with gitweb, unless it
is an obvious and trivial bugfix, is not meant for direct
inclusion).

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

On Tue, 3 Oct 2006, Junio C Hamano wrote:

> Honestly, I _hate_ to be in the position to decide in which
> color the bikeshed should be, but sometimes that is what a
> maintainer has to do.

Joys and tribulations of being maintainer... ;-)
 
> I personally feel that in a list that is one line per item, like
> the shortlog, we do not necessarily have to underline the log
> message even though they are clickable.  The purpose of the list
> is to show things so people can read them.  Readability matters.
> At the same time we would want to give access to object details;
> I think it is Ok not to give underline to them, as long as
> people can easily pick up the convention that each of these
> listed items is clickable to obtain details about it.

And the current convention of underlining "hidden links", like
the subject line in shortlog/log/heads/history view, is a good
hint of the convention.

> We should 
> probably make other clickable links at the right, such as "tree"
> and "snapshot", visually stand out, by giving underline as we
> already do.  They are not really "text", but clickable icons
> that happen to be done with text (as opposed to being done with
> img).

Additionally we use slightly smaller font for those links
(in addition to using default style for links).

> By the same logic, the purpose of the tree view is to show
> contents of a tree object.  If the user picks up the convention
> for the short log that each listed commit can be clicked to
> obtain details about it, it probably is natural for the user to
> expect that each listed entry in the tree view can be clicked to
> obtain details about it, so not showing the redundant tree/blob
> link is in line with that.  And it would be consistent not to
> give underline to the file or directory names.

I'd rather have underline for directory names to distinguish
it even more from files (blob entries), even for monochromatic
text display.


I am of two mind about removing "redundant" links movement.

First, I don't thing that avoiding redundancy in _user interface_
is a good argument. We sometimes add redundancy, for example in
commitdiff view for each patch we have sha1 of blob in the gitweb
header clickable, and obvously link, and we have the names of from
and to files in diff header "hidden links" and clickable. I could
agree with the argument about removing redundancy from the _code_,
and/or with the argument about _uncluttering_ interface.

Second, removing "redundant" links coupled with the fact that
the links the removed links duplicated cannot for mentioned resons
have default links style, so it is harder to guess that they are
links ("mystery meat navigation", although not in it's worst edition).
So there is tradeoff. Uncluttering the interface and simplifying
the code, but at the cost of gitweb interface being harder to beginners.
It is a question of policy then, do we cater to beginner users, or to
advanced users (which know/discovered that file name in tree view
and commit subject/title line in shortlog are links to respectively
blob view of a file and commit view of a commit).

Third, we should be consistent: either leave redundant links, perhaps
separating it by putting it into separate "selflink" column (see for 
example tags view), or remove redundat links where possible in all 
views.

-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Junio C Hamano]

BTW,

 - why do we have shortlog and log twice in the top navigation
   bar in commit view (a=commit)?

 - sometimes I'd like to view my tags sorted by name not by
   age.  Maybe we could add <sort-by> control on the age and
   name columns for git_tags_body()?

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Jakub Narebski]

Junio C Hamano wrote:
> BTW,
> 
>  - why do we have shortlog and log twice in the top navigation
>    bar in commit view (a=commit)?

Huh? I don't have shortlog and log twice in top navigation bar
in commit view
  a=commit;h=e70866f53a8d31cde6cfff6396ba0d1f64029afb
in gitweb/v1.4.2.3-gd98896b

>  - sometimes I'd like to view my tags sorted by name not by
>    age.  Maybe we could add <sort-by> control on the age and
>    name columns for git_tags_body()?
Could be done.

-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:
> BTW,
> 
>  - why do we have shortlog and log twice in the top navigation
>    bar in commit view (a=commit)?

It appears to be in the $extra argument to git_print_page_nav()
from git_commit() from cae1862a, lines 3033-3037.

    Luben


> 
>  - sometimes I'd like to view my tags sorted by name not by
>    age.  Maybe we could add <sort-by> control on the age and
>    name columns for git_tags_body()?
> 
> 
> 

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Luben Tuikov]

--- Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 3 Oct 2006, Junio C Hamano wrote:
> 
> > Honestly, I _hate_ to be in the position to decide in which
> > color the bikeshed should be, but sometimes that is what a
> > maintainer has to do.
> 
> Joys and tribulations of being maintainer... ;-)

Junio is doing an excellent job at maintaining GIT!  He's
tried to accomodate everyone, since this kind of flexibility
decides how many entities and companies adopt GIT and in return
this makes GIT better, by having those entities and companies
send back patches.  It is a well understood loop.

You should take a look at Linux and some subsystem's maintainers
"maintainership".  The worst thing by far that can happen to
a project being maintained is when "maintainership" becomes
the maintainer's _job_, as opposed to a professional (specializing
in a contingent field) who is doing maintainership in his spare
time. (i.e. the way it was in the 70s-80s with UNIX.)

Anyway, I digress, sorry.

> > By the same logic, the purpose of the tree view is to show
> > contents of a tree object.  If the user picks up the convention
> > for the short log that each listed commit can be clicked to
> > obtain details about it, it probably is natural for the user to
> > expect that each listed entry in the tree view can be clicked to
> > obtain details about it, so not showing the redundant tree/blob
> > link is in line with that.  And it would be consistent not to
> > give underline to the file or directory names.
> 
> I'd rather have underline for directory names to distinguish
> it even more from files (blob entries), even for monochromatic
> text display.

I strongly agree with Junio.  Intuition of gitweb spills in all
of its interfaces.  The nature of gitweb dictates that certain
things are clickable, simply because it is, after all, a web
interface to none other but GIT.

We don't need an overly explicit interface in gitweb, since gitweb
is not supposed to _teach_ git, but present it.

Take a look at other SCMs interfaces: perforce, cvs, clearcase, etc.

> I am of two mind about removing "redundant" links movement.
> 
> First, I don't thing that avoiding redundancy in _user interface_
> is a good argument. We sometimes add redundancy, for example in
> commitdiff view for each patch we have sha1 of blob in the gitweb
> header clickable, and obvously link, and we have the names of from
> and to files in diff header "hidden links" and clickable. I could
> agree with the argument about removing redundancy from the _code_,
> and/or with the argument about _uncluttering_ interface.
> 
> Second, removing "redundant" links coupled with the fact that
> the links the removed links duplicated cannot for mentioned resons
> have default links style, so it is harder to guess that they are
> links ("mystery meat navigation", although not in it's worst edition).
> So there is tradeoff. Uncluttering the interface and simplifying
> the code, but at the cost of gitweb interface being harder to beginners.

What "beginners" are you refering to?  GIT beginners or gitweb beginners?
gitweb is not supposed to be a teaching tool to GIT.

> It is a question of policy then, do we cater to beginner users, or to
> advanced users (which know/discovered that file name in tree view
> and commit subject/title line in shortlog are links to respectively
> blob view of a file and commit view of a commit).
> 
> Third, we should be consistent: either leave redundant links, perhaps
> separating it by putting it into separate "selflink" column (see for 
> example tags view), or remove redundat links where possible in all 
> views.

An absolutely excellent argument for the confines of a college course
paper or assignment on GUI.  Not very convicing to people with years
and years of experience in SCMs and what-not.

What we want is not some zelous argument about what is the "right"
way or the "proper" way (all very subjective) of doing the interface
of gitweb.  What we want is an intuitive and workable interface,
minimizing the number of eye movements, mouse movement, mouse clicks
to get to the information being sought.

    Luben

Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

[Linus Torvalds]

On Mon, 2 Oct 2006, Junio C Hamano wrote:
> 
> Honestly, I _hate_ to be in the position to decide in which
> color the bikeshed should be, but sometimes that is what a
> maintainer has to do.

Quite often, that's _exactly_ the one thing a maintainer should do. Most 
"non-bikeshed-painting" issues don't need maintainers. They are obvious to 
everybody, and/or there's only one person who actually did the work, and 
nobody else ends up beign competent enough, and people know it.

The real glory of maintainership isn't making the big and important 
decisions. The real glory lies in all the _small_ stuff that doesn't 
really matter, and that people will just argue forever.

The ability to just cut off the stupid debate early about something that 
otherwise never gets resolved (or that causes bad feelings just because 
people get worked up over some perceived issue), _that_ is what the 
maintainer is all about.

			Linus