{"thread":{"id":"5820","subject":"[PATCH] gitweb: Do not print \"log\" and \"shortlog\" redundantly in commit view","startedAt":"2006-10-05T19:22:57Z","lastAt":"2006-10-11T15:35:22Z","messageCount":54,"participants":["Luben Tuikov","Jakub Narebski","Petr Baudis","A Large Angry SCM","Junio C Hamano","Jeff King","Andreas Ericsson","Josef Weidendorfer"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"28244","messageId":"20061005192257.50209.qmail@web31809.mail.mud.yahoo.com","threadId":"5820","inReplyTo":null,"subject":"[PATCH] gitweb: Do not print \"log\" and \"shortlog\" redundantly in commit view","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-05T19:22:57Z","receivedAt":"2006-10-05T19:22:57Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"Do not print \"log\" and \"shortlog\" redundantly in commit\nview. This is passed into the $extra argument of\ngit_print_page_nav from git_commit, but git_print_page_nav\nprints \"log\" and \"shortlog\" already with the same head.\n\nNoticed by Junio.\n\nSigned-off-by: Luben Tuikov \n---\n gitweb/gitweb.perl | 5 -----\n 1 files changed, 0 insertions(+), 5 deletions(-)\n\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex bfd1405..65f1d82 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -3014,11 +3014,6 @@ sub git_commit {\n \t\t\t$cgi->a({-href => href(action=>\"blame\", hash_parent=>$parent, file_name=>$file_name)},\n \t\t\t \"blame\");\n \t}\n-\tif (defined $co{'parent'}) {\n-\t\tpush @views_nav,\n-\t\t\t$cgi->a({-href => href(action=>\"shortlog\", hash=>$hash)}, \"shortlog\"),\n-\t\t\t$cgi->a({-href => href(action=>\"log\", hash=>$hash)}, \"log\");\n-\t}\n \tgit_header_html(undef, $expires);\n \tgit_print_page_nav('commit', defined $co{'parent'} ? '' : 'commitdiff',\n \t $hash, $co{'tree'}, $hash,\n-- \n1.4.2.3.g2e575\n\n"},{"id":"28274","messageId":"eg51fi$7rs$2@sea.gmane.org","threadId":"5820","inReplyTo":"20061005192257.50209.qmail@web31809.mail.mud.yahoo.com","subject":"Re: [PATCH] gitweb: Do not print \"log\" and \"shortlog\" redundantly in commit view","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-06T07:44:29Z","receivedAt":"2006-10-06T07:44:29Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Luben Tuikov wrote:\n\n> Do not print \"log\" and \"shortlog\" redundantly in commit\n> view. This is passed into the $extra argument of\n> git_print_page_nav from git_commit, but git_print_page_nav\n> prints \"log\" and \"shortlog\" already with the same head.\n> \n> Noticed by Junio.\n> \n> Signed-off-by: Luben Tuikov \n\nGaah, the whole cae1862a3b55b487731e9857f2213ac59d5646d commit\n\"gitweb: More per-view navigation bar links\" is somewhat broken.\nUp to this point we used top navigation bar for commit (hash base)\nor whole project related links, while bottom part of navigation\nbar for \"formats\" i.e. links related to current view (passing hash)\nor for pagination.\n\nSo while \"snapshot\" link has it's place in top navigation bar\n(but by modyfying git_print_page_nav subroutine, not by adding it\nby hand), \"history\" for example IMHO doesn't; history link should be\npresent in the bottom part of navigation bar. Perhaps we could\nreuse git_print_page_nav for formats, for example blob wiew would have\n blob | _blame_ | _history_ | _raw_ | _HEAD_\nwhile tree view would have\n tree | _snapshot_ | _history_ | _HEAD_\n(where _text_ indices link). Perhaps _snapshot_ in tree view\nshouldn't be repeated, although top one might mean snapshot of commitish,\nbottom one snapshot of tree.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28301","messageId":"20061006163552.GT20017@pasky.or.cz","threadId":"5820","inReplyTo":"eg51fi$7rs$2@sea.gmane.org","subject":"Re: [PATCH] gitweb: Do not print \"log\" and \"shortlog\" redundantly in commit view","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-06T16:35:52Z","receivedAt":"2006-10-06T16:35:52Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Oct 06, 2006 at 09:44:29AM CEST, I got a letter\nwhere Jakub Narebski said that...\n> Gaah, the whole cae1862a3b55b487731e9857f2213ac59d5646d commit\n> \"gitweb: More per-view navigation bar links\" is somewhat broken.\n> Up to this point we used top navigation bar for commit (hash base)\n> or whole project related links, while bottom part of navigation\n> bar for \"formats\" i.e. links related to current view (passing hash)\n> or for pagination.\n\nUmm, and how did that commit break that? Except the issue this patch\nfixes - sorry about that, I have no idea wth was I thinking.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> Gaah, the whole cae1862a3b55b487731e9857f2213ac59d5646d commit\n> \"gitweb: More per-view navigation bar links\" is somewhat broken.\n> Up to this point we used top navigation bar for commit (hash base)\n> or whole project related links, while bottom part of navigation\n> bar for \"formats\" i.e. links related to current view (passing hash)\n> or for pagination.\n> \n> So while \"snapshot\" link has it's place in top navigation bar\n> (but by modyfying git_print_page_nav subroutine, not by adding it\n> by hand), \"history\" for example IMHO doesn't; history link should be\n> present in the bottom part of navigation bar. Perhaps we could\n> reuse git_print_page_nav for formats, for example blob wiew would have\n> blob | _blame_ | _history_ | _raw_ | _HEAD_\n> while tree view would have\n> tree | _snapshot_ | _history_ | _HEAD_\n> (where _text_ indices link). Perhaps _snapshot_ in tree view\n> shouldn't be repeated, although top one might mean snapshot of commitish,\n> bottom one snapshot of tree.\n\nOnly a single one: of committish please.\n\n Luben\n"},{"id":"28365","messageId":"20061007132457.GB20017@pasky.or.cz","threadId":"5820","inReplyTo":"20061006221603.50873.qmail@web31815.mail.mud.yahoo.com","subject":"Re: [PATCH] gitweb: Do not print \"log\" and \"shortlog\" redundantly in commit view","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-07T13:24:57Z","receivedAt":"2006-10-07T13:24:57Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Oct 07, 2006 at 12:16:03AM CEST, I got a letter\nwhere Luben Tuikov said that...\n> --- Jakub Narebski wrote:\n> > Gaah, the whole cae1862a3b55b487731e9857f2213ac59d5646d commit\n> > \"gitweb: More per-view navigation bar links\" is somewhat broken.\n> > Up to this point we used top navigation bar for commit (hash base)\n> > or whole project related links, while bottom part of navigation\n> > bar for \"formats\" i.e. links related to current view (passing hash)\n> > or for pagination.\n> > \n> > So while \"snapshot\" link has it's place in top navigation bar\n> > (but by modyfying git_print_page_nav subroutine, not by adding it\n> > by hand), \"history\" for example IMHO doesn't; history link should be\n> > present in the bottom part of navigation bar. Perhaps we could\n> > reuse git_print_page_nav for formats, for example blob wiew would have\n> > blob | _blame_ | _history_ | _raw_ | _HEAD_\n> > while tree view would have\n> > tree | _snapshot_ | _history_ | _HEAD_\n> > (where _text_ indices link). Perhaps _snapshot_ in tree view\n> > shouldn't be repeated, although top one might mean snapshot of commitish,\n> > bottom one snapshot of tree.\n> \n> Only a single one: of committish please.\n\nThen it will be impossible to get snapshot of any subtree (apart of\nmanually constructing the URL). Hmm, and it's a bug that we don't show\nthe snapshot link when listing tree entry in tree listing, I thought we\ndid in the past...?\n\nI think we should make it more clear what each of the bars concerns,\nperhaps doing some more significant redesign:\n\n[summary] is redundant, you have this big project name link in the top\nleft corner. All the other navbar options concern commit, so why not\nmerge it with the awkward commit box below the navbars?\n\nAll the \"views bar\" options concern the currently selected object, so\nwhy not merge it with the object \"descriptor\", that is the path?\n\nPatches will follow up.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Then it will be impossible to get snapshot of any subtree (apart of\n> manually constructing the URL). Hmm, and it's a bug that we don't show\n> the snapshot link when listing tree entry in tree listing, I thought\n> we did in the past...?\n> \n> I think we should make it more clear what each of the bars concerns,\n> perhaps doing some more significant redesign:\n> \n> [summary] is redundant, you have this big project name link in the top\n> left corner. All the other navbar options concern commit, so why not\n> merge it with the awkward commit box below the navbars?\n> \n> All the \"views bar\" options concern the currently selected object, so\n> why not merge it with the object \"descriptor\", that is the path?\n> \n> Patches will follow up.\n\nI think that \"summary\" has it's place rather in the bottom navigation \nbar, in the \"views bar\", because it is related to current object not \ncurrent commit (the \"tree\" entry in top navigation bar, \"actions bar\", \nis somewhat misleading because it actually is the tree of the commit, \nnot any tree). But the refactoring of \"views\" navigation bar is a good \nidea. For tree it would be\n\ttree | _history_ | _blame_ | _snapshot_\n(when there would be tree_blame back - there was short experiment, patch \non git list; snapshot of course only when enabled).\n\nI'd leave \"summary\" view, because the uther, especially with custome \n$home_link_str might be not obvous that it leads to summary view.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"28368","messageId":"20061007141040.16912.50717.stgit@rover","threadId":"5820","inReplyTo":"20061007132457.GB20017@pasky.or.cz","subject":"[PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-07T14:10:41Z","receivedAt":"2006-10-07T14:10:41Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Currently that's inconsistently reachable only by first displaying the\ntree.\n\nSigned-off-by: Petr Baudis \n---\n\n gitweb/gitweb.perl | 11 +++++++++--\n 1 files changed, 9 insertions(+), 2 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex c4970f4..096a01b 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -1752,7 +1752,7 @@ sub git_print_simplified_log {\n \n # print tree entry (row of git_tree), but without encompassing element\n sub git_print_tree_entry {\n-\tmy ($t, $basedir, $hash_base, $have_blame) = @_;\n+\tmy ($t, $basedir, $hash_base, $have_blame, $have_snapshot) = @_;\n \n \tmy %base_key = ();\n \t$base_key{hash_base} = $hash_base if defined $hash_base;\n@@ -1798,6 +1798,13 @@ sub git_print_tree_entry {\n \t\t\tprint $cgi->a({-href => href(action=>\"history\", hash_base=>$hash_base,\n \t\t\t file_name=>\"$basedir$t->{'name'}\")},\n \t\t\t \"history\");\n+\t\t\tif ($have_snapshot) {\n+\t\t\t\tprint \" | \";\n+\t\t\t}\n+\t\t}\n+\t\tif ($have_snapshot) {\n+\t\t\tprint $cgi->a({-href => href(action=>\"snapshot\", hash=>$t->{'hash'})},\n+\t\t\t\t \"snapshot\");\n \t\t}\n \t\tprint \"\\n\";\n \t}\n@@ -2931,7 +2938,7 @@ sub git_tree {\n \t\t}\n \t\t$alternate ^= 1;\n \n-\t\tgit_print_tree_entry(\\%t, $base, $hash_base, $have_blame);\n+\t\tgit_print_tree_entry(\\%t, $base, $hash_base, $have_blame, $have_snapshot);\n \n \t\tprint \"\\n\";\n \t}\n"},{"id":"28369","messageId":"20061007141043.16912.73982.stgit@rover","threadId":"5820","inReplyTo":"20061007132457.GB20017@pasky.or.cz","subject":"[PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-07T14:10:43Z","receivedAt":"2006-10-07T14:10:43Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Signed-off-by: Petr Baudis \n---\n\n gitweb/gitweb.perl | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex 096a01b..c3d09a2 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -1791,7 +1791,7 @@ sub git_print_tree_entry {\n \t\tprint \"\";\n \t\tprint $cgi->a({-href => href(action=>\"tree\", hash=>$t->{'hash'},\n \t\t file_name=>\"$basedir$t->{'name'}\", %base_key)},\n-\t\t esc_html($t->{'name'}));\n+\t\t esc_html($t->{'name'} . '/'));\n \t\tprint \"\\n\";\n \t\tprint \"\";\n \t\tif (defined $hash_base) {\n"},{"id":"28371","messageId":"20061007141721.GC20017@pasky.or.cz","threadId":"5820","inReplyTo":"200610071605.23277.jnareb@gmail.com","subject":"Re: [PATCH] gitweb: Do not print \"log\" and \"shortlog\" redundantly in commit view","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-07T14:17:21Z","receivedAt":"2006-10-07T14:17:21Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Oct 07, 2006 at 04:05:22PM CEST, I got a letter\nwhere Jakub Narebski said that...\n> Petr Baudis wrote:\n> > Then it will be impossible to get snapshot of any subtree (apart of\n> > manually constructing the URL). Hmm, and it's a bug that we don't show\n> > the snapshot link when listing tree entry in tree listing, I thought\n> > we did in the past...?\n> > \n> > I think we should make it more clear what each of the bars concerns,\n> > perhaps doing some more significant redesign:\n> > \n> > [summary] is redundant, you have this big project name link in the top\n> > left corner. All the other navbar options concern commit, so why not\n> > merge it with the awkward commit box below the navbars?\n> > \n> > All the \"views bar\" options concern the currently selected object, so\n> > why not merge it with the object \"descriptor\", that is the path?\n\nTo make the idea more graphic:\n\nCommit title master shortlog | log | commit | commitdiff | tree\n\n[project.git] / subdir / filename blame | history | raw | HEAD\n\n\nOr perhaps first the navigation, then the title.\n\n> > Patches will follow up.\n\nI have decided to reprioritize and do other stuff now. I will get back\nto it sometime later if noone does it first.\n\n> I think that \"summary\" has it's place rather in the bottom navigation \n> bar, in the \"views bar\", because it is related to current object not \n> current commit (the \"tree\" entry in top navigation bar, \"actions bar\", \n> is somewhat misleading because it actually is the tree of the commit, \n> not any tree).\n\nIt's not related to current object any more than to the current commit\nand is really out-of-place in both bars. It's related only to the\ncurrent project.\n\nWe _do_ have a project-global bar at each page. It's the footer,\ncontaining the description and RSS link. What about stashing it there?\n;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> Currently that's inconsistently reachable only by first displaying the\n> tree.\n\nI cannot say that there is any \"inconsistency\" there per se. I also\nfail to see the value of this patch.\n\nIt looks like it just adds interface to gitweb, just because \"we can\"\nand \"gitweb can do it\".\n\n Luben\n\n> \n> Signed-off-by: Petr Baudis \n> ---\n> \n> gitweb/gitweb.perl | 11 +++++++++--\n> 1 files changed, 9 insertions(+), 2 deletions(-)\n> \n> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\n> index c4970f4..096a01b 100755\n> --- a/gitweb/gitweb.perl\n> +++ b/gitweb/gitweb.perl\n> @@ -1752,7 +1752,7 @@ sub git_print_simplified_log {\n> \n> # print tree entry (row of git_tree), but without encompassing element\n> sub git_print_tree_entry {\n> -\tmy ($t, $basedir, $hash_base, $have_blame) = @_;\n> +\tmy ($t, $basedir, $hash_base, $have_blame, $have_snapshot) = @_;\n> \n> \tmy %base_key = ();\n> \t$base_key{hash_base} = $hash_base if defined $hash_base;\n> @@ -1798,6 +1798,13 @@ sub git_print_tree_entry {\n> \t\t\tprint $cgi->a({-href => href(action=>\"history\", hash_base=>$hash_base,\n> \t\t\t file_name=>\"$basedir$t->{'name'}\")},\n> \t\t\t \"history\");\n> +\t\t\tif ($have_snapshot) {\n> +\t\t\t\tprint \" | \";\n> +\t\t\t}\n> +\t\t}\n> +\t\tif ($have_snapshot) {\n> +\t\t\tprint $cgi->a({-href => href(action=>\"snapshot\", hash=>$t->{'hash'})},\n> +\t\t\t\t \"snapshot\");\n> \t\t}\n> \t\tprint \"\\n\";\n> \t}\n> @@ -2931,7 +2938,7 @@ sub git_tree {\n> \t\t}\n> \t\t$alternate ^= 1;\n> \n> -\t\tgit_print_tree_entry(\\%t, $base, $hash_base, $have_blame);\n> +\t\tgit_print_tree_entry(\\%t, $base, $hash_base, $have_blame, $have_snapshot);\n> \n> \t\tprint \"\\n\";\n> \t}\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"28377","messageId":"20061007184148.GE20017@pasky.or.cz","threadId":"5820","inReplyTo":"20061007183702.40162.qmail@web31802.mail.mud.yahoo.com","subject":"Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-07T18:41:48Z","receivedAt":"2006-10-07T18:41:48Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Oct 07, 2006 at 08:37:02PM CEST, I got a letter\nwhere Luben Tuikov said that...\n> --- Petr Baudis wrote:\n> > Currently that's inconsistently reachable only by first displaying the\n> > tree.\n> \n> I cannot say that there is any \"inconsistency\" there per se. I also\n> fail to see the value of this patch.\n\nCurrently the bottom navbar is more or less the same as the list of\nlinks in the tree entry (there's the HEAD link but that's a special\ncase).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> Signed-off-by: Petr Baudis \n> ---\n\nFirst, this is a Unixism, and would confuse other OS users.\nSecond, \"/\" is after all _not part of the name_ of the tree/directory,\nbut part of the filesystem's path separator, let's not export it\nto users of other OS's.\nThird, directories/trees are already clearly \n 1) underlined, and\n 2) differently colored,\nwhich makes it overly obvious what it what.\n\nIn fact, my eyes only scan for the different color/underlined\nentries when I'm searching for a directory in tree view. I don't even\nlook at the left-most column.\n\nNACK!\n\n Luben\n\n> \n> gitweb/gitweb.perl | 2 +-\n> 1 files changed, 1 insertions(+), 1 deletions(-)\n> \n> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\n> index 096a01b..c3d09a2 100755\n> --- a/gitweb/gitweb.perl\n> +++ b/gitweb/gitweb.perl\n> @@ -1791,7 +1791,7 @@ sub git_print_tree_entry {\n> \t\tprint \"\";\n> \t\tprint $cgi->a({-href => href(action=>\"tree\", hash=>$t->{'hash'},\n> \t\t file_name=>\"$basedir$t->{'name'}\", %base_key)},\n> -\t\t esc_html($t->{'name'}));\n> +\t\t esc_html($t->{'name'} . '/'));\n> \t\tprint \"\\n\";\n> \t\tprint \"\";\n> \t\tif (defined $hash_base) {\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"28380","messageId":"20061007185253.90045.qmail@web31810.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"20061007184148.GE20017@pasky.or.cz","subject":"Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-07T18:52:53Z","receivedAt":"2006-10-07T18:52:53Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Petr Baudis wrote:\n> Dear diary, on Sat, Oct 07, 2006 at 08:37:02PM CEST, I got a letter\n> where Luben Tuikov said that...\n> > --- Petr Baudis wrote:\n> > > Currently that's inconsistently reachable only by first displaying the\n> > > tree.\n> > \n> > I cannot say that there is any \"inconsistency\" there per se. I also\n> > fail to see the value of this patch.\n> \n> Currently the bottom navbar is more or less the same as the list of\n> links in the tree entry (there's the HEAD link but that's a special\n> case).\n\nI completely understand where you're coming from. I do.\n\nBut this patch makes the view so much more cluttered. And it isn't\nvital. Yes we can do it, yes gitweb can do it, but I doubt the core\nvalue.\n\nAnother thing is that currently tree/directory entries' third (links)\ncolumn to be shortest of all, and this gives my eyes another indication\nthat this is a tree.\n\nImagine a long list of files, and in the middle a directory. Then\nyou'd see only the \"history\" link next to it, as opposed to the long\n\"history | snapshot\"...\n\nI'm ambivalent as to whether this goes in or not. If the people want it,\nso be it.\n\n Luben\n\n\n> \n> -- \n> \t\t\t\tPetr \"Pasky\" Baudis\n> Stuff: http://pasky.or.cz/\n> #!/bin/perl -sp0777i $/=unpack('H*',$_);$_=`echo 16dio\\U$k\"SK$/SM$n\\EsN0p[lN*1\n> lK[d2%Sa2/d0$^Ixp\"|dc`;s/\\W//g;$_=pack('H*',/((..)*)$/)\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"28381","messageId":"eg8tpu$drj$1@sea.gmane.org","threadId":"5820","inReplyTo":"20061007184418.64881.qmail@web31812.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-07T19:06:25Z","receivedAt":"2006-10-07T19:06:25Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Luben Tuikov wrote:\n\n> --- Petr Baudis wrote:\n>> + esc_html($t->{'name'} . '/'));\n> \n> First, this is a Unixism, and would confuse other OS users.\nBut AFAIK _Git_ uses it, in output and in index.\n\n> Second, \"/\" is after all _not part of the name_ of the tree/directory,\n> but part of the filesystem's path separator, let's not export it\n> to users of other OS's.\n> Third, directories/trees are already clearly \n> 1) underlined, and\n> 2) differently colored,\n> which makes it overly obvious what it what.\n> \n> In fact, my eyes only scan for the different color/underlined\n> entries when I'm searching for a directory in tree view. I don't even\n> look at the left-most column.\n> \n> NACK!\n\nI'd rather like it.\n\n\nMore important though would be to add better support for symlinks,\nperhaps in the UNIX form\n\n symlink -> _target_\n\nWhete _text_ denotes link.\n\nBy the way, I miss somewhat the \"redundant\" tree/blob links in tree\nview...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28383","messageId":"20061007191246.GF20017@pasky.or.cz","threadId":"5820","inReplyTo":"eg8tpu$drj$1@sea.gmane.org","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-07T19:12:46Z","receivedAt":"2006-10-07T19:12:46Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Oct 07, 2006 at 09:06:25PM CEST, I got a letter\nwhere Jakub Narebski said that...\n> Luben Tuikov wrote:\n> \n> > --- Petr Baudis wrote:\n> >> + esc_html($t->{'name'} . '/'));\n> > \n> > First, this is a Unixism, and would confuse other OS users.\n\ndrwxr-xr-x\n\n> By the way, I miss somewhat the \"redundant\" tree/blob links in tree\n> view...\n\nI didn't want to post about it but I share the feeling - I have to keep\nthinking consciously about clicking on the file name instead of on the\nview name - and the situation is worse for regular files, since it is\nnot really apparent that the filenames are clickablea. My mind knows\nthat I'm supposed to click on them (not users' mind!), but the eyes and\nhands are still clueless.\n\nSo, I'd like to either have the view links or the filenames in classical\nlink style so that it's apparent they are clickable; I didn't post a\npatch since I didn't have time/energy to fight for it yet. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i said that...\n> Another thing is that currently tree/directory entries' third (links)\n> column to be shortest of all, and this gives my eyes another indication\n> that this is a tree.\n\nWhat would people think about first listing all the trees, then all the\nblobs? Just like LANG=C ls does, as well as cvsweb and overally most of\nthe rest of the relevant world.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i So, I'd like to either have the view links or the filenames in classical\n> link style so that it's apparent they are clickable; I didn't post a\n> patch since I didn't have time/energy to fight for it yet. ;-)\n\nThere is a tradeout. Either have easily distinguishable directories and\nfiles, by using both different color and decoration (underline), or we have\nfilename/directory name clearly marked as link. One or the other.\n\nThat is why I'd rather have this \"redundant\" blob/tree link (perhaps in\nseparate column).\n\nBut this is a matter of policy, unless we want to add theme support to\ngitweb ;-))\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28392","messageId":"20061007211531.GH20017@pasky.or.cz","threadId":"5820","inReplyTo":"eg9378$rln$1@sea.gmane.org","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-07T21:15:31Z","receivedAt":"2006-10-07T21:15:31Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Oct 07, 2006 at 10:38:51PM CEST, I got a letter\nwhere Jakub Narebski said that...\n> Petr Baudis wrote:\n> \n> > So, I'd like to either have the view links or the filenames in classical\n> > link style so that it's apparent they are clickable; I didn't post a\n> > patch since I didn't have time/energy to fight for it yet. ;-)\n> \n> There is a tradeout. Either have easily distinguishable directories and\n> files, by using both different color and decoration (underline), or we have\n> filename/directory name clearly marked as link. One or the other.\n> \n> That is why I'd rather have this \"redundant\" blob/tree link (perhaps in\n> separate column).\n\nAs I suggested in another mail, perhaps the whole problem is wrong and\nyou shouldn't have to dug for trees in a bunch of blobs in the first\nplace - let's group all the trees at the top, as all the well-behaved\ndirectory listings do.\n\n> But this is a matter of policy, unless we want to add theme support to\n> gitweb ;-))\n\nWe _do_ have that - you can supply your own gitweb.css. But the defaults\nshould be sensible.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Dear diary, on Sat, Oct 07, 2006 at 10:38:51PM CEST, I got a letter\n> where Jakub Narebski said that...\n>> Petr Baudis wrote:\n>> \n>> > So, I'd like to either have the view links or the filenames in classical\n>> > link style so that it's apparent they are clickable; I didn't post a\n>> > patch since I didn't have time/energy to fight for it yet. ;-)\n>> \n>> There is a tradeout. Either have easily distinguishable directories and\n>> files, by using both different color and decoration (underline), or we have\n>> filename/directory name clearly marked as link. One or the other.\n>> \n>> That is why I'd rather have this \"redundant\" blob/tree link (perhaps in\n>> separate column).\n> \n> As I suggested in another mail, perhaps the whole problem is wrong and\n> you shouldn't have to dug for trees in a bunch of blobs in the first\n> place - let's group all the trees at the top, as all the well-behaved\n> directory listings do.\n\nIt is a good idea, although we would wither to have to read the directory\n(tree) listing first into some array, then sort it directories first\n(contrary to current output while reading, which reduces latency provided\nthat browser can properly display partial contents), or add some option\nto git-ls-tree command to output tree entries (directories) first, instead\nof sorting by filename.\n\n>> But this is a matter of policy, unless we want to add theme support to\n>> gitweb ;-))\n> \n> We _do_ have that - you can supply your own gitweb.css. But the defaults\n> should be sensible.\n\nTheme support, as to be able to choose theme, like style selectable from\nweb browser, and for example choosing if the tree/blob links are present\nor not. Some of which might be done via CSS (display:none).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28394","messageId":"45281CBF.7030405@gmail.com","threadId":"5820","inReplyTo":"20061007184418.64881.qmail@web31812.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2006-10-07T21:31:43Z","receivedAt":"2006-10-07T21:31:43Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Luben Tuikov wrote:\n> --- Petr Baudis wrote:\n>> Signed-off-by: Petr Baudis \n>> ---\n> \n> First, this is a Unixism, and would confuse other OS users.\n> Second, \"/\" is after all _not part of the name_ of the tree/directory,\n> but part of the filesystem's path separator, let's not export it\n> to users of other OS's.\n> Third, directories/trees are already clearly \n> 1) underlined, and\n> 2) differently colored,\n> which makes it overly obvious what it what.\n> \n> In fact, my eyes only scan for the different color/underlined\n> entries when I'm searching for a directory in tree view. I don't even\n> look at the left-most column.\n\nNot that I care that much, but\n 1) not all browsers show underlines (try some text mode browsers)\n 2) not all browsers show colors (try some text mode browsers)\n 2) not all people see all colors\n"},{"id":"28398","messageId":"7vr6xjpxlc.fsf@assigned-by-dhcp.cox.net","threadId":"5820","inReplyTo":"20061007191552.GG20017@pasky.or.cz","subject":"Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-07T22:31:11Z","receivedAt":"2006-10-07T22:31:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Dear diary, on Sat, Oct 07, 2006 at 08:52:53PM CEST, I got a letter\n> where Luben Tuikov said that...\n>> Another thing is that currently tree/directory entries' third (links)\n>> column to be shortest of all, and this gives my eyes another indication\n>> that this is a tree.\n>\n> What would people think about first listing all the trees, then all the\n> blobs? Just like LANG=C ls does, as well as cvsweb and overally most of\n> the rest of the relevant world.\n\nMildly negative but I do not have strong preference.\n\nBTW, I do not get what you mean by \"LANG=C ls\".\n"},{"id":"28399","messageId":"7vmz87pxg6.fsf@assigned-by-dhcp.cox.net","threadId":"5820","inReplyTo":"20061007184418.64881.qmail@web31812.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-07T22:34:17Z","receivedAt":"2006-10-07T22:34:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> --- Petr Baudis wrote:\n>> Signed-off-by: Petr Baudis \n>> ---\n>\n> First, this is a Unixism, and would confuse other OS users.\n> Second, \"/\" is after all _not part of the name_ of the tree/directory,\n> but part of the filesystem's path separator, let's not export it\n> to users of other OS's.\n> Third, directories/trees are already clearly \n> 1) underlined, and\n> 2) differently colored,\n> which makes it overly obvious what it what.\n\nI was actually hoping that we can get rid of the differences you\ncited above.\n\nUnderlines make entries harder to read, and colouring is \ndistracting; some people do not see all colours and to them it\nmay not distracting but then they need another way to notice the\ndifferences between tree/blob.\n"},{"id":"28402","messageId":"20061008010424.85913.qmail@web31812.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"20061007191552.GG20017@pasky.or.cz","subject":"Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-08T01:04:24Z","receivedAt":"2006-10-08T01:04:24Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Petr Baudis wrote:\n> Dear diary, on Sat, Oct 07, 2006 at 08:52:53PM CEST, I got a letter\n> where Luben Tuikov said that...\n> > Another thing is that currently tree/directory entries' third (links)\n> > column to be shortest of all, and this gives my eyes another indication\n> > that this is a tree.\n> \n> What would people think about first listing all the trees, then all the\n> blobs? Just like LANG=C ls does, as well as cvsweb and overally most of\n> the rest of the relevant world.\n\nI don't like it and the reason is that when I'm searching for something\nI expect the listing to be alphabetically sorted, period.\nNot type-then-alphabetical, which is greatly distracting and only makes\nme lose 3-10 seconds looking for the item I'm looking at.\n\nBunching up the directories at the top and then listing the files at\nthe bottom is one of those great annoyances.\n\nBut, if you do implement that, please make it configurable, because\nI'll resort to the current listing order.\n\n Luben\n"},{"id":"28403","messageId":"20061008011634.844.qmail@web31814.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"7vmz87pxg6.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-08T01:16:34Z","receivedAt":"2006-10-08T01:16:34Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> > --- Petr Baudis wrote:\n> >> Signed-off-by: Petr Baudis \n> >> ---\n> >\n> > First, this is a Unixism, and would confuse other OS users.\n> > Second, \"/\" is after all _not part of the name_ of the tree/directory,\n> > but part of the filesystem's path separator, let's not export it\n> > to users of other OS's.\n> > Third, directories/trees are already clearly \n> > 1) underlined, and\n> > 2) differently colored,\n> > which makes it overly obvious what it what.\n> \n> I was actually hoping that we can get rid of the differences you\n> cited above.\n> \n> Underlines make entries harder to read, and colouring is \n> distracting; some people do not see all colours and to them it\n> may not distracting but then they need another way to notice the\n> differences between tree/blob.\n\nI know, I've seen your email on that and have your patch with the\nicons applied at work. But it is black and white and I'd rather\nsee some nice color and shading if we're going to change that.\n\nI don't mind using nice warm color icons in the left-most column.\n\n Luben\n"},{"id":"28461","messageId":"20061009205551.GO20017@pasky.or.cz","threadId":"5820","inReplyTo":"20061007191246.GF20017@pasky.or.cz","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-09T20:55:51Z","receivedAt":"2006-10-09T20:55:51Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"> Dear diary, on Sat, Oct 07, 2006 at 09:06:25PM CEST, I got a letter\n> where Jakub Narebski said that...\n> > By the way, I miss somewhat the \"redundant\" tree/blob links in tree\n> > view...\n> \n> I didn't want to post about it but I share the feeling - I have to keep\n> thinking consciously about clicking on the file name instead of on the\n> view name - and the situation is worse for regular files, since it is\n> not really apparent that the filenames are clickablea. My mind knows\n> that I'm supposed to click on them (not users' mind!), but the eyes and\n> hands are still clueless.\n\nI was looking into accesslogs of repo.or.cz for something and noticed\nthat I see unusually large number of blame requests. That of course\nattracted my curiosity and I came to conclusion that what I'm seeing is\nnot just my personal whim but we have serious usability problem here.\n\nI'm unfortunately not sure when the update of repo.or.cz gitweb which\ndropped the blob/tree links happenned, so the following _is_ somewhat\ndubious, but I think it's quite telling anyway.\n\nI have three samples (logfiles) available: #2 almost certainly when the\nblob link was still there, #1 covering the switch and some time before\nand after, and #0 certainly when the blob link was not there anymore,\nbut unfortunately spanning only one or two days.\n\nThis is the count of actions invoked from the tree, commit and\ncommitdiff view (using the referer information):\n\n blame blob total requests containing 'a='\n#2 1 18 264\n#1 31 23 399\n#0 4 6 50\n\nThe disparation between #2 and #1,#0 is quite apparent. If we want more\nexact results, I will let #0 accumulate data for a week and then revert\nthe removal of the links and start another sample.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i writes:\n\n> This is the count of actions invoked from the tree, commit and\n> commitdiff view (using the referer information):\n>\n> blame blob total requests containing 'a='\n> #2 1 18 264\n> #1 31 23 399\n> #0 4 6 50\n>\n> The disparation between #2 and #1,#0 is quite apparent. If we want more\n> exact results, I will let #0 accumulate data for a week and then revert\n> the removal of the links and start another sample.\n\nI am not sure -- you are certainly counting me looking at your\nblame output while working on the slimmed down blame output (you\nmay remember that I noted that while your output gives names and\ndates for each line which is busier I kind of liked it in one of\nmy previous messages), and we talked about gitweb blame lot\nrecently on the list so that might have spurred people's\ncuriosity.\n"},{"id":"28485","messageId":"7vy7ro7o3g.fsf@assigned-by-dhcp.cox.net","threadId":"5820","inReplyTo":"7vslhx9k6c.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-10T05:10:27Z","receivedAt":"2006-10-10T05:10:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Petr Baudis writes:\n>\n>> This is the count of actions invoked from the tree, commit and\n>> commitdiff view (using the referer information):\n>>\n>> blame blob total requests containing 'a='\n>> #2 1 18 264\n>> #1 31 23 399\n>> #0 4 6 50\n>>\n>> The disparation between #2 and #1,#0 is quite apparent. If we want more\n>> exact results, I will let #0 accumulate data for a week and then revert\n>> the removal of the links and start another sample.\n>\n> I am not sure -- you are certainly counting me looking at your\n> blame output while working on the slimmed down blame output (you\n> may remember that I noted that while your output gives names and\n> dates for each line which is busier I kind of liked it in one of\n> my previous messages), and we talked about gitweb blame lot\n> recently on the list so that might have spurred people's\n> curiosity.\n\nHaving said that, I agree to the point you are trying to make\nhere. It was a mistake to remove blob/tree links from the view\nthat lists pathnames.\n\nIf we did not have any obviously clickable links on the right\nhand side it might have been a different story, but when given\nUNIXy permission bits, pathname and blame/history/raw links,\nnobody would think of clicking on the pathname itself to grab\nits contents. The blame link would give you the same\ninformation (and a bit more) and people would just go there\nwithout much thinking.\n\nIt probably is wise to resurrect those \"redundant\" links.\n"},{"id":"28487","messageId":"20061010053841.42852.qmail@web31815.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"7vy7ro7o3g.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-10T05:38:41Z","receivedAt":"2006-10-10T05:38:41Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Having said that, I agree to the point you are trying to make\n> here. It was a mistake to remove blob/tree links from the view\n> that lists pathnames.\n> \n> If we did not have any obviously clickable links on the right\n> hand side it might have been a different story, but when given\n> UNIXy permission bits, pathname and blame/history/raw links,\n> nobody would think of clicking on the pathname itself to grab\n> its contents. The blame link would give you the same\n\nI've seen the exact opposite.\n\nBTW, what is our standard here? People with zero-computer\nexposure? With some? With high?\n\nCertainly, if I didn't know what a folder/directory/tree is,\nand what a file is and I was told to \"get\" that file, the first\nthing I'd do when I see it on the screen would be to \"put my pointer\nover the file and press the action button\".\n\nIt is when people actually start to \"think\" is when they fail\nto naively click on the pathname (name of the file) to get it.\n\nThe naive approach is to simply click on what you want to get.\n\nThe interesting point here is that people with zero and high\ncomputer exposure tend to click on the file name to obtain it.\nOnly people with some computer exposure start to \"think\" and\n\"figure it out\" and fail to intuit to naively point at the\nfile name to get the file. \n\nSo this is 2/3 to 1/3.\n\n> information (and a bit more) and people would just go there\n> without much thinking.\n> \n> It probably is wise to resurrect those \"redundant\" links.\n\nIf someone does this, can they also remove the now \"other\"\nredundant link? (the link at the pathname itself) A simple\ncode analyzer would show the duplicate code in gitweb.\n\n Luben\n"},{"id":"28488","messageId":"7vslhw7mfm.fsf@assigned-by-dhcp.cox.net","threadId":"5820","inReplyTo":"20061010053841.42852.qmail@web31815.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-10T05:46:21Z","receivedAt":"2006-10-10T05:46:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> --- Junio C Hamano wrote:\n>> Having said that, I agree to the point you are trying to make\n>> here. It was a mistake to remove blob/tree links from the view\n>> that lists pathnames.\n>> \n>> If we did not have any obviously clickable links on the right\n>> hand side it might have been a different story, but when given\n>> UNIXy permission bits, pathname and blame/history/raw links,\n>> nobody would think of clicking on the pathname itself to grab\n>> its contents. The blame link would give you the same\n>\n> I've seen the exact opposite.\n>\n> BTW, what is our standard here? People with zero-computer\n> exposure? With some? With high?\n>\n> Certainly, if I didn't know what a folder/directory/tree is,\n> and what a file is and I was told to \"get\" that file, the first\n> thing I'd do when I see it on the screen would be to \"put my pointer\n> over the file and press the action button\".\n\nI would agree with that if we did not have anything on the right\nhand side that attracts eye and hand to tempt clicking. And\nthat would be true for all levels of users.\n\nIf we replaced UNIXy mode bits with folder/file/symlink icons,\npeople might be tempted to click on them as well.\n"},{"id":"28489","messageId":"20061010054643.GA565@coredump.intra.peff.net","threadId":"5820","inReplyTo":"20061010053841.42852.qmail@web31815.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-10T05:46:43Z","receivedAt":"2006-10-10T05:46:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 09, 2006 at 10:38:41PM -0700, Luben Tuikov wrote:\n\n> The interesting point here is that people with zero and high\n> computer exposure tend to click on the file name to obtain it.\n> Only people with some computer exposure start to \"think\" and\n> \"figure it out\" and fail to intuit to naively point at the\n> file name to get the file. \n> \n> So this is 2/3 to 1/3.\n\n2/3 to 1/3 if you're counting categories, but you haven't presented any\nevidence that the number of people in each category is the same.\n\nBesides which, I think that people with a high degree of exposure to the\nweb tend to look for the things that look like buttons or links. The\nnear-universal sign for links on the web is underlining (and typically\nan alternate color). Looking at the repo.or.cz file lists, I see that\nnone of the files is highlighted but the directories are. What am I to\nguess (either by intuition or by \"figuring it out\") except that there is\nsome difference between clicking the two? I think we are failing a\nconsistency test.\n\n-Peff\n"},{"id":"28490","messageId":"20061010062126.46664.qmail@web31810.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"20061009205551.GO20017@pasky.or.cz","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-10T06:21:26Z","receivedAt":"2006-10-10T06:21:26Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Petr Baudis wrote:\n> I was looking into accesslogs of repo.or.cz for something and noticed\n> that I see unusually large number of blame requests. That of course\n> attracted my curiosity and I came to conclusion that what I'm seeing is\n> not just my personal whim but we have serious usability problem here.\n> \n> I'm unfortunately not sure when the update of repo.or.cz gitweb which\n> dropped the blob/tree links happenned, so the following _is_ somewhat\n> dubious, but I think it's quite telling anyway.\n> \n> I have three samples (logfiles) available: #2 almost certainly when the\n> blob link was still there, #1 covering the switch and some time before\n> and after, and #0 certainly when the blob link was not there anymore,\n> but unfortunately spanning only one or two days.\n> \n> This is the count of actions invoked from the tree, commit and\n> commitdiff view (using the referer information):\n> \n> blame blob total requests containing 'a='\n> #2 1 18 264\n> #1 31 23 399\n> #0 4 6 50\n> \n> The disparation between #2 and #1,#0 is quite apparent. If we want more\n> exact results, I will let #0 accumulate data for a week and then revert\n> the removal of the links and start another sample.\n\nOh, my, oh, my.\n\nAnyone can come up with any \"statistic\" to convince anyone of\nanything. It's the American way! (to financial success)\n\nI mean, I can even give you a mathematical series which I can add\nin certain orders to give me any number I want... Which is not at\nall intutitive.\n\nAnyway, the \"confused\" link clearly says \"blame\". I'm not sure why\nyour people were trying to think and figure it out, as opposed to\nsimply clicking on the file name itself. It is the most intuitive\nthing to do as I mentioned in my previous email.\n\nDid you do any demographics on your clickers? What is their background?\nDid you try to calculate how statistically correct your sample is\nand if the clickers represent the general computer population out there?\nWhat is your sampling error?\n\nI can hardly accept this \"statistic\" as a proof to \"reintroduce\nthe redundant links\".\n\nBut I give up.\n\nIf you guys want the redundant links back in, so be it -- submit\na patch.\n\nThen let's fortify gitweb, because we can. Lets add links and more\nredundancy to fortify the user interface so that all and any possibilities\nare covered. And as soon as a NEW git facility is introduced, then\nwe'll add 10 or 20 more links to gitweb for this just one, single\nnew facility. Then with each new single facility if it is related to\nany other, the number of links would grow exponentially. Then after\nsuch and such time has passed, let's look at the code. Then let's\nask if someone has left maintaining the then gitweb jungle. More\nimportantly, let's ask if someone has left _using_ it. (That would\nbe the ripe time to start afresh with gitweb2.perl.)\n\nAs long as job is being done and the patches are flowing in, and\nmore and more code is introduced, albeit redundantly, we shouldn't\ncare what the people who use this every day want or care for.\n\nHey, let's add more links!\n\n Luben\nP.S. I'll go and collect some statistics now.\n"},{"id":"28492","messageId":"20061010063431.92880.qmail@web31807.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"7vslhw7mfm.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-10T06:34:31Z","receivedAt":"2006-10-10T06:34:31Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> I would agree with that if we did not have anything on the right\n> hand side that attracts eye and hand to tempt clicking. And\n> that would be true for all levels of users.\n> \n> If we replaced UNIXy mode bits with folder/file/symlink icons,\n> people might be tempted to click on them as well.\n\nThen they should probably \"get\" the jpg/png image of the icon, ;-)\neach time they click on it. If they really wanted the file, then\nthey should probably just simply click on the file name.\n\n Luben\n"},{"id":"28494","messageId":"20061010064117.86409.qmail@web31813.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"20061010054643.GA565@coredump.intra.peff.net","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-10T06:41:17Z","receivedAt":"2006-10-10T06:41:17Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Jeff King wrote:\n> 2/3 to 1/3 if you're counting categories, but you haven't presented any\n> evidence that the number of people in each category is the same.\n> \n> Besides which, I think that people with a high degree of exposure to the\n> web tend to look for the things that look like buttons or links. The\n> near-universal sign for links on the web is underlining (and typically\n\nThen let's universally underline absolutely _every_ link in gitweb\nwhich is clickable, regardless of where it appears, the font, typeset\nand size.\n\nWho will be my hero and submit that patch? I'll surely commit it\nand make the people happy.\n\n> an alternate color). Looking at the repo.or.cz file lists, I see that\n> none of the files is highlighted but the directories are. What am I to\n> guess (either by intuition or by \"figuring it out\") except that there is\n> some difference between clicking the two? I think we are failing a\n> consistency test.\n\nLet's see:\n\nEach line which starts with a \"d\" also has some kind of underlined\ntext in the second column.\n\nEach line which starts with a \"-\" has text which is not underlined\nin the second column.\n\nWhich implies a connection between the \"d\" and the property of\nunderlining.\n\nUnless you have \"a priori\" knowlege of \"underline means clickable\" there\nis no chance of thinking that \"not-underlined means not-clickable\".\n\n Luben\n"},{"id":"28496","messageId":"20061010065849.GA2413@coredump.intra.peff.net","threadId":"5820","inReplyTo":"20061010064117.86409.qmail@web31813.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-10T06:58:49Z","receivedAt":"2006-10-10T06:58:49Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 09, 2006 at 11:41:17PM -0700, Luben Tuikov wrote:\n\n> Then let's universally underline absolutely _every_ link in gitweb\n> which is clickable, regardless of where it appears, the font, typeset\n> and size.\n\nInstead, let's make a strawman argument!\n\nThough I agree that it would be nicer for ALL links in gitweb to be\nconsistent, I think there is an argument to be made about look. However,\nthe specific example I mentioned is a single list in which some elements\nare underlined and blue (which has been the classic user interface hint\nfor a link for a decade), and some aren't. Do you see why I think that\nmight be inconsistent?\n\n> Unless you have \"a priori\" knowlege of \"underline means clickable\" there\n\nWhich was my argument in the first place (note that I was talking about\npeople with a high degree of computer exposure).\n\n> is no chance of thinking that \"not-underlined means not-clickable\".\n\nThere is clearly a non-zero chance. Here's a relatively ridiculous\nargument.\n\nLook at the 'summary' page for a project. For each commit, there are\nblue and underlined 'commitdiff', 'text', and 'snapshot' links. The\ndate, author, and message text have no such decoration. I click on the\nunderlined things and see that they are all links. I click on date and\nauthor and see they are not links. The pattern of underlining links has\nheld for five out of six elements. Do you think it's unreasonable to\nguess that the sixth element is not a link based on that pattern?\n\n\nLook, I agree that not underlining everything might make the page look\nnicer. And if we want to balance consistency against aesthetics, that's\nfine. But please don't argue that there isn't an inconsistency.\n\n-Peff\n"},{"id":"28497","messageId":"20061010070531.GB2413@coredump.intra.peff.net","threadId":"5820","inReplyTo":"20061010062126.46664.qmail@web31810.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-10T07:05:31Z","receivedAt":"2006-10-10T07:05:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 09, 2006 at 11:21:26PM -0700, Luben Tuikov wrote:\n\n> Anyone can come up with any \"statistic\" to convince anyone of\n> anything. It's the American way! (to financial success)\n\nPetr introduced quantitative evidence and an analysis. You can argue\nthat his numbers or his analysis are incorrect, but berating statistics\nas a whole is not a compelling argument.\n\n> Anyway, the \"confused\" link clearly says \"blame\". I'm not sure why\n> your people were trying to think and figure it out, as opposed to\n> simply clicking on the file name itself. It is the most intuitive\n> thing to do as I mentioned in my previous email.\n\nIs it? I think the point of Petr's data is to show that, for whatever\nreason, people are NOT intuitively doing as you expect.\n\n> Did you do any demographics on your clickers? What is their background?\n\nAren't they, by definition, gitweb users? And isn't that the target\ndemographic? You can argue that there are potential gitweb users who\nwill behave completely differently, but I haven't seen any evidence to\nsupport that claim.\n\n> I can hardly accept this \"statistic\" as a proof to \"reintroduce\n> the redundant links\".\n\nIt's not a proof. It's evidence in support of a claim. Sorry, but this\nisn't math.\n\n-Peff\n"},{"id":"28500","messageId":"452B54A5.4080901@op5.se","threadId":"5820","inReplyTo":"20061010070531.GB2413@coredump.intra.peff.net","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-10T08:07:01Z","receivedAt":"2006-10-10T08:07:01Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"This discussion has taken a wrong turn and ended up somewhere in the \nmurky backwaters of questionable sanity.\n\nI like my links blue and underlined. Can't be arsed to mouse over things \nto figure out if they're clickable. If they're not blue and underlined, \nthey're not, insofar as I'm concerned.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"28501","messageId":"7vac4460dj.fsf@assigned-by-dhcp.cox.net","threadId":"5820","inReplyTo":"20061010070531.GB2413@coredump.intra.peff.net","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-10T08:28:08Z","receivedAt":"2006-10-10T08:28:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Oct 09, 2006 at 11:21:26PM -0700, Luben Tuikov wrote:\n>\n>> Anyone can come up with any \"statistic\" to convince anyone of\n>> anything. It's the American way! (to financial success)\n>\n> Petr introduced quantitative evidence and an analysis. You can argue\n> that his numbers or his analysis are incorrect, but berating statistics\n> as a whole is not a compelling argument.\n\nAlthough I tend to agree with Pasky, I think Luben has a point\nin that the click count he quoted does not have enough samples\nand also tainted by known skews (both Gitzilla and I have\nadmitted that we hit blames unnecessarily not because we wanted\nto see the blamed project but because we wanted to see how the\nblame on his site shows things) to draw any meaningful\nconclusion.\n\nBut that is as far as I would go agreeing with Luben on this\nthread. If we did not have anything else that obviously are\nclickable it might be natural to expect people to click on\notherwise unhighlighted filenames to grab the blob data. But\nthe current layout that shows filenames in plain and a few\nobviously clickable links on the same line draws eyes and mouse\naway from the filename and to the links on the right hand side,\neven for somebody like me, who intellectually knows (because I\nmerged it) that the filenames in trees ought to be clickable.\n"},{"id":"28505","messageId":"egfo99$lg6$2@sea.gmane.org","threadId":"5820","inReplyTo":"20061010053841.42852.qmail@web31815.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-10T09:15:22Z","receivedAt":"2006-10-10T09:15:22Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Luben Tuikov wrote:\n\n>> It probably is wise to resurrect those \"redundant\" links.\n> \n> If someone does this, can they also remove the now \"other\"\n> redundant link? (the link at the pathname itself) A simple\n> code analyzer would show the duplicate code in gitweb.\n\nEasy, easy now.\n\n\nI'd rather add some more \"hidden\" links, but for each hidden\nlink (which are convenience only, to have larger are to click,\nor to have closer area to click) I'd like to have clearly marked\nlink (marked as a link, i.e. using default link style; and with link text\ndenoting _kind_ of link) which leads to the same contents. \n\nFor example on project list page I would made also project description\n(and not only project name) clickable, leading tp project summary.\nMaking project name direct link wouldn't work for sites like kernel.org\nwith long (hierarchical) project names like\n linux/kernel/git/wim/linux-2.6-watchdog-experimental.git\nAnd for other sites project name is/can be bit on the short side.\n\nBut we agreed (I guess) to disagree on the whole redundancy in user\ninterface issue (although I agree on the issue of reducing clutter).\nBTW. we can reduce redundancy in the code without need for removing\n\"alternate entry points\" in interface, I think.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28513","messageId":"200610101514.20705.Josef.Weidendorfer@gmx.de","threadId":"5820","inReplyTo":"452B54A5.4080901@op5.se","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-10-10T13:14:17Z","receivedAt":"2006-10-10T13:14:17Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 10 October 2006 10:07, Andreas Ericsson wrote:\n> I like my links blue and underlined. Can't be arsed to mouse over things \n> to figure out if they're clickable. If they're not blue and underlined, \n> they're not, insofar as I'm concerned.\n\nSame opinion here.\n\nBetter be functional than beautiful but confusing.\n\nIf Gitweb would be a desktop application, we would have context menues\nfor different actions on list items, but that is not really possible\nwith web pages (?), and would be unexpected.\n\nGitweb is a web interface. So lets use the conventions for web pages.\nOne solution is to repeat the actions everytime in every row of a list,\nas we do now (and I think is fine; we could use icons instead). The other\nstandard solution is to have checkboxes at the front of every row, and\nthe actions as buttons, which means two mouse clicks (which IMHO is a\nreally bad UI).\n\nAnd as we go with the first solution, we explicitly should state all\npossible actions, and not provide an hidden action which is triggered\nwhen clicking on the entry name. Currently, it is not very clear that\n* we have a \"blob\" action at all,\n* clicking on the entry name provides the blob action. Seems to me\nlike an arbitrary choice. Why not \"raw\" or \"blame\" instead?\nTherefore, I am in favor of reintroducing the \"blob\" link,\nwhich allows the entry names to stay as they are\nnow (and could get the hidden redundant action).\n\nOne thing I found confusing in this regard the first time:\nWhy do list rows show a recoloring with mouse over?\nThis somehow suggest that the whole row makes up some kind of\na button and is clickable (BTW, blame pages do not do this).\nCan we get rid of this?\n\nJosef\n"},{"id":"28534","messageId":"20061010182343.18986.qmail@web31808.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"200610101514.20705.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-10T18:23:43Z","receivedAt":"2006-10-10T18:23:43Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Josef Weidendorfer wrote:\n> One thing I found confusing in this regard the first time:\n> Why do list rows show a recoloring with mouse over?\n\nIt's a highlight and it's a good highlight. It suggests that the\nrow is \"alive\", i.e. that the title is clickable. It \"shows\" you\nyour current \"selection\" by having the mouse pointer over the row.\n\nI like it.\n\n Luben\n"},{"id":"28536","messageId":"20061010185006.34796.qmail@web31813.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"200610101514.20705.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-10T18:50:06Z","receivedAt":"2006-10-10T18:50:06Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Josef Weidendorfer wrote:\n> On Tuesday 10 October 2006 10:07, Andreas Ericsson wrote:\n> > I like my links blue and underlined. Can't be arsed to mouse over things \n> > to figure out if they're clickable. If they're not blue and underlined, \n> > they're not, insofar as I'm concerned.\n> \n> Same opinion here.\n> \n> Better be functional than beautiful but confusing.\n\nIndeed.\n\nThe larger the group of people deciding on an issue, the less\nforward ideas and thinking is introduced. They are inversely\nproportional.\n\nNote that almost all forward ideas and ground breaking thoughts have\nalways been introduced by one, at most two people, not in a forum\nor committee. For example (relavant to the audience of this list):\nLinux, git, sparse.\n\nImagine if the design of git has been initiated in a committee or\na mailing list or a forum...\n\nCan someone please submit those two patches\n a) one which underlines ALL clickable links in ALL of gitweb, and\n b) second which puts redundant links of everything to everything,\n just because we can,\nand then we can move on?\n\nThanks,\n Luben\n"},{"id":"28537","messageId":"200610102052.36055.Josef.Weidendorfer@gmx.de","threadId":"5820","inReplyTo":"20061010182343.18986.qmail@web31808.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-10-10T18:52:35Z","receivedAt":"2006-10-10T18:52:35Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 10 October 2006 20:23, Luben Tuikov wrote:\n> --- Josef Weidendorfer wrote:\n> > One thing I found confusing in this regard the first time:\n> > Why do list rows show a recoloring with mouse over?\n> \n> It's a highlight and it's a good highlight. It suggests that the\n> row is \"alive\", i.e. that the title is clickable.\n\nIf you look e.g. at a gitweb shortlog, neither the first nor the\nsecond column is clickable. Still, there is this highlighting.\nI remember I clicked and wondered that nothing is happening.\n\n> It \"shows\" you \n> your current \"selection\" by having the mouse pointer over the row.\n\nAs you can do nothing with this \"selection\", it really makes no\nsense to show it. If you could make this selection permanent by\nclicking on the row, and do some actions on your selection,\nit would be different.\n\nIMHO, a valid argument would be that this highlighting makes it\neasier to quickly see which information in different columns belong\ntogether, especially when much whitespace is used.\nBut for this, alternative coloring of rows is enough.\n\nJosef\n"},{"id":"28541","messageId":"20061010191904.99261.qmail@web31809.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"egfo99$lg6$2@sea.gmane.org","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-10T19:19:04Z","receivedAt":"2006-10-10T19:19:04Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Jakub Narebski wrote:\n> Luben Tuikov wrote:\n> \n> >> It probably is wise to resurrect those \"redundant\" links.\n> > \n> > If someone does this, can they also remove the now \"other\"\n> > redundant link? (the link at the pathname itself) A simple\n> > code analyzer would show the duplicate code in gitweb.\n> \n> Easy, easy now.\n\nCan you please CC me when replying to a post of mine? Else\nI have to go chase in the git folder as opposed it coming to\nmy inbox. Thanks!\n\n> I'd rather add some more \"hidden\" links, but for each hidden\n> link (which are convenience only, to have larger are to click,\n> or to have closer area to click) I'd like to have clearly marked\n> link (marked as a link, i.e. using default link style; and with link text\n> denoting _kind_ of link) which leads to the same contents. \n\nWhy would you like all this? If users start using those other links\nall the time, what is the purpose of the \"hidden\" links as you call them?\n\nConsider the \"tree\" link between \"commitdiff\" and \"snapshot\" (if enabled)\nin shortlog view.\n\nConsider the \"hidden\" link of each entry (file/directory).\n\nCan you see how they are different?\n\nIntroducing this to an engineer who has little knowlege about git:\n \"Click on the file or directory name, to get the file or go into\n the directory\"\nSimple and intuitive, no need to mention \"blob\" or \"tree\" or \"object\".\nOr,\n \"Click on the 'blob' link to get the ... Click on the 'tree' link to\n get the ... Oh you didn't know what a 'tree' or 'blob' object is?\n A 'blob' is ... A 'tree' is ...\"\n\nAt which point the engineer has lost 90% of his interest.\n\nIt even gets even worse for the obnoxious \"tree\" link next to each commit\nin shortlog view:\n \"The tree link is the the tree object which is part of a commit object.\n Oh you don't know the internals of a commit object? A commit object\n binds a tree object and a (parent) commit object, but blah, blah, blah...\"\n\nCan you see how all this apparent \"simplicity\" you're trying to introduce\ncontradics the mere links you're introducing it with?\n\nSurely \"we can\", but should we? The \"tree\" link in shortlog next to each commit\nis one such example of \"we can\", but we shouldn't.\n\nThe question is: Given the average engineer, what is the gitweb interface\nsuch that they can start using it fastest with the minimum amount of\nquestions?\n\n> But we agreed (I guess) to disagree on the whole redundancy in user\n> interface issue (although I agree on the issue of reducing clutter).\n> BTW. we can reduce redundancy in the code without need for removing\n> \"alternate entry points\" in interface, I think.\n\nClutter and redundancy is just a part of it. A larger part is\nhow much git or non-git oriented we want to make the interface, which\nseems related to the overall simplicity and intuitiveness.\n\nThe golden question:\nWhat is the interface such that both git-experts and never-seen-git-\nbut-know-about-SCMs engineers can find it intuitive to use with minimal\namount of questions?\n\n Luben\n"},{"id":"28544","messageId":"7vvemsymdx.fsf@assigned-by-dhcp.cox.net","threadId":"5820","inReplyTo":"20061010191904.99261.qmail@web31809.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-10T19:57:30Z","receivedAt":"2006-10-10T19:57:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> Or,\n> \"Click on the 'blob' link to get the ... Click on the 'tree' link to\n> get the ... Oh you didn't know what a 'tree' or 'blob' object is?\n> A 'blob' is ... A 'tree' is ...\"\n>\n> At which point the engineer has lost 90% of his interest.\n>\n> It even gets even worse for the obnoxious \"tree\" link next to each commit\n> in shortlog view:\n> \"The tree link is the the tree object which is part of a commit object.\n> Oh you don't know the internals of a commit object? A commit object\n> binds a tree object and a (parent) commit object, but blah, blah, blah...\"\n\nIsn't that a simple \"labelling\" question? I do not think\nanybody minds to show clickable string \"contents\" (instead of\n\"blob\" or \"tree\") at the places you mention above and if we did\nso everybody would be happy, right?\n"},{"id":"28550","messageId":"200610102229.35642.jnareb@gmail.com","threadId":"5820","inReplyTo":"20061010191904.99261.qmail@web31809.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-10T20:29:35Z","receivedAt":"2006-10-10T20:29:35Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Luben Tuikov wrote:\n> --- Jakub Narebski wrote:\n>> Luben Tuikov wrote:\n>> \n>>>> It probably is wise to resurrect those \"redundant\" links.\n>>> \n>>> If someone does this, can they also remove the now \"other\"\n>>> redundant link? (the link at the pathname itself) A simple\n>>> code analyzer would show the duplicate code in gitweb.\n>>\n>> I'd rather add some more \"hidden\" links, but for each hidden\n>> link (which are convenience only, to have larger are to click,\n>> or to have closer area to click) I'd like to have clearly marked\n>> link (marked as a link, i.e. using default link style; and with\n>> link text denoting _kind_ of link) which leads to the same contents. \n> \n> Why would you like all this? If users start using those other links\n> all the time, what is the purpose of the \"hidden\" links as you call\n> them? \n\nIt was answered in the part you haven't quoted. Sometimes \"hidden link\" \npurpose it is to have larger area where we can click, for example in \n\"tree\" view the name of file (the name of directory is not hidden, as\nit uses default link style), in \"shortlog\"/\"heads\"/\"tags\" view the title\n(subject) of a commit/ref. Sometimes it is to have link closer, for\nexample name of files in diff header being \"hidden link\" to file \ncontents before and after the change.\n\n\"Hidden links\" are in fact half hidden, as I think all of them are \nunderlined on mouseover. \n\nBut, as I have said, we cannot use default link style for those \"hidden \nlinks\", either because as in \"shortlog\" view this would negatively \naffect readibility, or it would clash with syntax highlighting as in \nthe case of \"commitdiff\" and \"blobdiff\" views, or because we have two \ntypes of object we want to be visually distinct, but there is only one \ndefault style of links like in the case of directory (tree) and file \n(blob) entries in the \"tree\" view.\n \n> Consider the \"tree\" link between \"commitdiff\" and \"snapshot\" \n> (if enabled) in shortlog view.\n> \n> Consider the \"hidden\" link of each entry (file/directory).\n> \n> Can you see how they are different?\n\nYes, \"tree\" link is small, blue (if not visited), and underlined.\nBut I guess that wasn't what you had in mind.\n\nIMPORTANT: By the way, by removing 'redundant' \"blob\"/\"tree\" link we \nremove the possibility of denoting which links (which directories and \nfiles) we have visited (sic!).\n\n> Introducing this to an engineer who has little knowlege about git:\n> \"Click on the file or directory name, to get the file or go into\n> the directory\"\n> Simple and intuitive, no need to mention \"blob\" or \"tree\" or \"object\".\n> Or,\n> \"Click on the 'blob' link to get the ... Click on the 'tree' link\n> to get the ... Oh you didn't know what a 'tree' or 'blob' object\n> is? A 'blob' is ... A 'tree' is ...\"\n>\n> At which point the engineer has lost 90% of his interest.\n\nThe links are for git and gitweb users. They tell (we assume that git \nuser knows what blob, tree, etc. means; we assume that gitweb user \nknows what blob views or tree view means)\n \"Click on the 'blob' link to get 'blob' view for current line file\"\nlike the \"history\" link tells\n \"Click on the 'history' link to get history of a current line file\"\n\nFor example \"hidden link\" of title/subject of a commit in \"shortlog\" or \n\"history\" view doesn't tell us what kind of view it leads too: commit, \ncommitdiff? Well, it doesn't tell us that it is link, either... ;-)\n\n> It even gets even worse for the obnoxious \"tree\" link next to each\n> commit in shortlog view:\n> \"The tree link is the the tree object which is part of a commit\n> object. Oh you don't know the internals of a commit object?\n> A commit object binds a tree object and a (parent) commit object,\n> but blah, blah, blah...\" \n> \n> Can you see how all this apparent \"simplicity\" you're trying to\n> introduce contradics the mere links you're introducing it with?\n\nI don't understand you. The \"tree\" link in shortlog is a _shortcut_ to \nthe \"tree\" view (and I think that one can guess that tree view means \ndirectory listing in the state as saved by given commit), without it \nyou would have to do it in two steps, first going to commit view, then \nclicking on tree in the main navbar. So it is IMHO usefull.\n\nPerhaps you meant \"tree\" header in \"commit\" view? There surely we could \nuse ordinary link style for sha1 which is tree identifier. Cause surely \nwe don't need for the sha1 to be readable, as in the case of commit \ntitle in the shortlog view. Additionally it would serve as a way to \ndistinguish on first glance which headers are clickable, and which are \nnot. And there we could I guess loose redundant headers.\n\n[...]\n\n> The question is: Given the average engineer, what is the gitweb\n> interface such that they can start using it fastest with the minimum\n> amount of questions?\n\nGiven average user/programmer... \n\n>> But we agreed (I guess) to disagree on the whole redundancy in user\n>> interface issue (although I agree on the issue of reducing clutter).\n>> BTW. we can reduce redundancy in the code without need for removing\n>> \"alternate entry points\" in interface, I think.\n> \n> Clutter and redundancy is just a part of it. A larger part is\n> how much git or non-git oriented we want to make the interface, which\n> seems related to the overall simplicity and intuitiveness.\n\nOne must pay atention to not to make interface _too simple_, and less \nusable because of it. And definition of intuitiveness depends on the \nperson...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"28551","messageId":"200610102231.37136.jnareb@gmail.com","threadId":"5820","inReplyTo":"7vvemsymdx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-10T20:31:36Z","receivedAt":"2006-10-10T20:31:36Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> > Or,\n> > \"Click on the 'blob' link to get the ... Click on the 'tree' link to\n> > get the ... Oh you didn't know what a 'tree' or 'blob' object is?\n> > A 'blob' is ... A 'tree' is ...\"\n> >\n> > At which point the engineer has lost 90% of his interest.\n> >\n> > It even gets even worse for the obnoxious \"tree\" link next to each commit\n> > in shortlog view:\n> > \"The tree link is the the tree object which is part of a commit object.\n> > Oh you don't know the internals of a commit object? A commit object\n> > binds a tree object and a (parent) commit object, but blah, blah, blah...\"\n> \n> Isn't that a simple \"labelling\" question? I do not think\n> anybody minds to show clickable string \"contents\" (instead of\n> \"blob\" or \"tree\") at the places you mention above and if we did\n> so everybody would be happy, right?\n\nNot, IMHO it is not a good idea. Clicking on file name leads to it\ncontents, but it is not obvoius what kind of view is it. \"blob\" link\nleads to blob view, \"tree\" link leads to tree view, which are known\nwhat they mean to any git user.\n-- \nJakub Narebski\nPoland\n"},{"id":"28549","messageId":"20061010205238.33892.qmail@web31803.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"7vvemsymdx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-10T20:52:38Z","receivedAt":"2006-10-10T20:52:38Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> > Or,\n> > \"Click on the 'blob' link to get the ... Click on the 'tree' link to\n> > get the ... Oh you didn't know what a 'tree' or 'blob' object is?\n> > A 'blob' is ... A 'tree' is ...\"\n> >\n> > At which point the engineer has lost 90% of his interest.\n> >\n> > It even gets even worse for the obnoxious \"tree\" link next to each commit\n> > in shortlog view:\n> > \"The tree link is the the tree object which is part of a commit object.\n> > Oh you don't know the internals of a commit object? A commit object\n> > binds a tree object and a (parent) commit object, but blah, blah, blah...\"\n> \n> Isn't that a simple \"labelling\" question? I do not think\n\nNot quite. You have to explain to the engineer that the \"tree\" link\nnext to each \"comit title\" \"shows\" the project _at the state of that\ncommit_. Which is the WORST PR for git and gitweb. Why?\n\nBecause now you have to explain internals of git and gitweb.\n\nInstead of letting the engineer click on the commit to see the commit\nand then the commit provides a _context_ where \"tree\" makes much more\nintuitive sense.\n\nOTOH, if one is an expert in git, then they have no problem\ngetting to the information: commit->tree.\n\n> anybody minds to show clickable string \"contents\" (instead of\n> \"blob\" or \"tree\") at the places you mention above and if we did\n\nWell, \"contents\" of a commit is a tricky thing. This is why I don't\nlike the \"tree\" link next to each commit in shortlog, but didn't mention\nanything when the patch was posted a couple of days ago.\n\nIt is just an unnecessary \"fast forward interpretation\" of commit.\n\n> so everybody would be happy, right?\n\nI don't know anymore.\n\n Luben\nP.S. Notice how there is a \"snapshot\" link on each line of\nshortlog, but there is no \"snapshot\" link in the nav bar\nof a=commit. The \"snapshot\" link is next to \"tree\" down\nin the commit data. There is also a \"tree\" link which is also\nin the navbar, but \"shortlog\" is missing.\n"},{"id":"28553","messageId":"200610102300.16935.jnareb@gmail.com","threadId":"5820","inReplyTo":"20061010205238.33892.qmail@web31803.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-10T21:00:16Z","receivedAt":"2006-10-10T21:00:16Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Luben Tuikov wrote:\n> P.S. Notice how there is a \"snapshot\" link on each line of\n> shortlog, but there is no \"snapshot\" link in the nav bar\n> of a=commit.  The \"snapshot\" link is next to \"tree\" down\n> in the commit data.  There is also a \"tree\" link which is also\n> in the navbar, but \"shortlog\" is missing.\n\nThe problem with snapshot is that we can have snapshot of a commit\n(and all links in the top part of navigation bar till now deals with \ncurrent commit), and snapshot of a tree, which can be subdirectory\n(and all links in the bottom part of navigation bar deals with \nthe views/presentations of a current object).\n-- \nJakub Narebski\nPoland\n"},{"id":"28554","messageId":"20061010210226.47626.qmail@web31809.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"200610102231.37136.jnareb@gmail.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-10T21:02:25Z","receivedAt":"2006-10-10T21:02:25Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Jakub Narebski wrote:\n> Junio C Hamano wrote:\n> > Luben Tuikov writes:\n> > \n> > > Or,\n> > > \"Click on the 'blob' link to get the ... Click on the 'tree' link to\n> > > get the ... Oh you didn't know what a 'tree' or 'blob' object is?\n> > > A 'blob' is ... A 'tree' is ...\"\n> > >\n> > > At which point the engineer has lost 90% of his interest.\n> > >\n> > > It even gets even worse for the obnoxious \"tree\" link next to each commit\n> > > in shortlog view:\n> > > \"The tree link is the the tree object which is part of a commit object.\n> > > Oh you don't know the internals of a commit object? A commit object\n> > > binds a tree object and a (parent) commit object, but blah, blah, blah...\"\n> > \n> > Isn't that a simple \"labelling\" question? I do not think\n> > anybody minds to show clickable string \"contents\" (instead of\n> > \"blob\" or \"tree\") at the places you mention above and if we did\n> > so everybody would be happy, right?\n> \n> Not, IMHO it is not a good idea. Clicking on file name leads to it\n> contents, but it is not obvoius what kind of view is it. \"blob\" link\n\nIt is pretty obvious to me: the contents of the object, whether it be\n\"blob\" or \"tree\". The contents of \"blob\" and the contents of \"tree\"\nas shown by gitweb.\n\n Luben\n\n\n> leads to blob view, \"tree\" link leads to tree view, which are known\n> what they mean to any git user.\n> -- \n> Jakub Narebski\n> Poland\n> \n"},{"id":"28556","messageId":"200610102313.48170.jnareb@gmail.com","threadId":"5820","inReplyTo":"20061010210226.47626.qmail@web31809.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-10T21:13:47Z","receivedAt":"2006-10-10T21:13:47Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia wtorek 10. października 2006 23:02, Luben Tuikov napisał:\n> > > Isn't that a simple \"labelling\" question?  I do not think\n> > > anybody minds to show clickable string \"contents\" (instead of\n> > > \"blob\" or \"tree\") at the places you mention above and if we did\n> > > so everybody would be happy, right?\n> > \n> > Not, IMHO it is not a good idea. Clicking on file name leads to it\n> > contents, but it is not obvoius what kind of view is it. \"blob\" link\n> \n> It is pretty obvious to me: the contents of the object, whether it be\n> \"blob\" or \"tree\".  The contents of \"blob\" and the contents of \"tree\"\n> as shown by gitweb.\n\nIt's pretty obvous to you, because there is only one basic view of tree, \nand one basic view of blob. It is not the case for example for commits \nin shortlog view, where we have commit and commitdiff views. It is \npossible that either blobs or trees acquire another views.\n-- \nJakub Narebski\nPoland\n"},{"id":"28560","messageId":"20061010221458.85789.qmail@web31804.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"200610102300.16935.jnareb@gmail.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-10T22:14:58Z","receivedAt":"2006-10-10T22:14:58Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Jakub Narebski wrote:\n> Luben Tuikov wrote:\n> > P.S. Notice how there is a \"snapshot\" link on each line of\n> > shortlog, but there is no \"snapshot\" link in the nav bar\n> > of a=commit. �The \"snapshot\" link is next to \"tree\" down\n> > in the commit data. �There is also a \"tree\" link which is also\n> > in the navbar, but \"shortlog\" is missing.\n> \n> The problem with snapshot is that we can have snapshot of a commit\n> (and all links in the top part of navigation bar till now deals with \n> current commit), and snapshot of a tree, which can be subdirectory\n> (and all links in the bottom part of navigation bar deals with \n> the views/presentations of a current object).\n\nOh, yes, that's exactly what we need: two links of the same name\n(\"snapshot\") in the top row of navbar and in the bottom row of navbar.\n\n Luben\n"},{"id":"28563","messageId":"20061010221853.98520.qmail@web31807.mail.mud.yahoo.com","threadId":"5820","inReplyTo":"200610102313.48170.jnareb@gmail.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-10T22:18:53Z","receivedAt":"2006-10-10T22:18:53Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Jakub Narebski wrote:\n> Dnia wtorek 10. pa�dziernika 2006 23:02, Luben Tuikov napisa�:\n> > > > Isn't that a simple \"labelling\" question? �I do not think\n> > > > anybody minds to show clickable string \"contents\" (instead of\n> > > > \"blob\" or \"tree\") at the places you mention above and if we did\n> > > > so everybody would be happy, right?\n> > > \n> > > Not, IMHO it is not a good idea. Clicking on file name leads to it\n> > > contents, but it is not obvoius what kind of view is it. \"blob\" link\n> > \n> > It is pretty obvious to me: the contents of the object, whether it be\n> > \"blob\" or \"tree\". �The contents of \"blob\" and the contents of \"tree\"\n> > as shown by gitweb.\n> \n> It's pretty obvous to you, because there is only one basic view of tree, \n> and one basic view of blob. It is not the case for example for commits \n> in shortlog view, where we have commit and commitdiff views. It is \n> possible that either blobs or trees acquire another views.\n\nExcuse me, weren't we talking about \"blob\" and \"tree\"?\n\nHow come you all of a sudden introduce commits? Let's keep on topic:\n\"blob\" and \"tree\".\n\n Luben\n"},{"id":"28567","messageId":"200610110040.21235.jnareb@gmail.com","threadId":"5820","inReplyTo":"20061010221458.85789.qmail@web31804.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-10T22:40:20Z","receivedAt":"2006-10-10T22:40:20Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia środa 11. października 2006 00:14, Luben Tuikov napisał:\n> --- Jakub Narebski wrote:\n> > Luben Tuikov wrote:\n> > > P.S. Notice how there is a \"snapshot\" link on each line of\n> > > shortlog, but there is no \"snapshot\" link in the nav bar\n> > > of a=commit. The \"snapshot\" link is next to \"tree\" down\n> > > in the commit data. There is also a \"tree\" link which is also\n> > > in the navbar, but \"shortlog\" is missing.\n> > \n> > The problem with snapshot is that we can have snapshot of a commit\n> > (and all links in the top part of navigation bar till now deals with \n> > current commit), and snapshot of a tree, which can be subdirectory\n> > (and all links in the bottom part of navigation bar deals with \n> > the views/presentations of a current object).\n> \n> Oh, yes, that's exactly what we need: two links of the same name\n> (\"snapshot\") in the top row of navbar and in the bottom row of navbar.\n\nI'm mentioning the problem, that \"snapshot\" has two meaning for a tree.\nI personally think that we should have commit snapshot links (with \ncommit sha in the extended tar header if we use tgz snapshots) for \n\"heads\", \"tags\" and \"project list\" views, and perhaps in the \"commit\" \nand optionally \"commitdiff\" view; perhaps but not necessary for each \ncommit-list view like log, shortlog, search, history. But the snapshot \nlink should be as a view of a (sub)directory only in the bottom part of \nnavigation bar.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"28605","messageId":"452D0F3A.1080800@op5.se","threadId":"5820","inReplyTo":"20061010191904.99261.qmail@web31809.mail.mud.yahoo.com","subject":"Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-11T15:35:22Z","receivedAt":"2006-10-11T15:35:22Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Luben Tuikov wrote:\n> \n> The question is: Given the average engineer, what is the gitweb interface\n> such that they can start using it fastest with the minimum amount of\n> questions?\n> \n\nOriginally, the question was about average gitweb users. I'm sorry \nLuben, but as long as you propagate links that are not\na) blue\nb) underlined\nI'll have to disagree with everything you say out of pure principle.\n\n> \n> The golden question:\n> What is the interface such that both git-experts and never-seen-git-\n> but-know-about-SCMs engineers can find it intuitive to use with minimal\n> amount of questions?\n> \n\nJust make links blue and underlined and people will click them out of \ncuriousity. 100% guaranteed. Try to spoonfeed engineers and they will \nspit on you, because engineers like to figure things out, even if \nthey're obvious. Try to make things intuitive for average users and you \nwill be wrong, because intuition is highly culture- and experience \noriented. Try to make it foolproof and you will fail, because fools are \nso ingenious.\n\nThe one and only thing everyone looking at a gitweb interface has in \ncommon is curiousity, so appeal to that rather than trying any of the \ndoomed paths above.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"}]}