{"thread":{"id":"5163","subject":"[PATCH/RFC] gitweb: Great subroutines renaming","startedAt":"2006-08-07T14:26:52Z","lastAt":"2006-08-14T00:11:30Z","messageCount":30,"participants":["Jakub Narebski","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"24922","messageId":"200608071626.52655.jnareb@gmail.com","threadId":"5163","inReplyTo":null,"subject":"[PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-07T14:26:52Z","receivedAt":"2006-08-07T14:26:52Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"This RFC is about better naming of subroutines in gitweb. The patch was\ngenerated on top of 'next' (7c7e45d0cc0f482aeb19ecb0b56e9e7b65472c56)\nusing embedded gitweb-rename.sh script.\n\n\nIf one would want to apply patch which was generated without \n\"subroutine renaming\" on top of branch which includes it, simply\nrun gitweb-unrename.sh, apply patch, run gitweb-rename.sh, commit.\n\nIf one would want to apply patch which was created with new subroutine\nnames on top of branch which doesn not include \"subroutine renaming\"\ncommit, simply run gitweb-rename.sh, apply patch, run gitweb-unrename.sh,\nthen commit.\n\nAnd in such a case patch calculus, with non-patch operators like those\nscripts, is useful.\n\n\nHow should subroutines be named? Do you agree with proposal, or not?\nIs such renaming usefull?\n\nComments? Thought?\n\n-- >8 -- gitweb-rename.sh --\n#/bin/sh\n\nrm -f gitweb.perl.re~\necho \"Great subroutine renaming\"\nperl -s -p -i.re~ \\\n\t-e 's/\\bgit_get_referencing\\b/format_mark_referencing/;' \\\n\t-e 's/\\bgit_read_head\\b/git_get_head/;' \\\n\t-e 's/\\bread_info_ref\\b/git_read_info_refs/;' \\\n\t-e 's/\\bdate_str\\b/parse_date/;' \\\n\t-e 's/\\bgit_read_tag\\b/parse_tag/;' \\\n\t-e 's/\\bgit_read_commit\\b/parse_commit/;' \\\n\t-e 's/\\bgit_blob_plain_mimetype\\b/blob_plain_mimetype/;' \\\n\t-e 's/\\bgit_page_nav\\b/git_print_page_nav/;' \\\n\t-e 's/\\bgit_header_div\\b/git_print_header_div/;' \\\n\tgitweb.perl\n\n# end of gitweb-rename.sh\n\n-- >8 -- gitweb-unrename.sh --\n#/bin/sh\n\nrm -f gitweb.perl.un~\necho \"Reverting Great subroutine renaming\"\nperl -s -p -i.un~ \\\n\t-e 's/\\bformat_mark_referencing\\b/git_get_referencing/;' \\\n\t-e 's/\\bgit_get_head\\b/git_read_head/;' \\\n\t-e 's/\\bgit_read_info_refs\\b/read_info_ref/;' \\\n\t-e 's/\\bparse_date\\b/date_str/;' \\\n\t-e 's/\\bparse_tag\\b/git_read_tag/;' \\\n\t-e 's/\\bparse_commit\\b/git_read_commit/;' \\\n\t-e 's/\\bblob_plain_mimetype\\b/git_blob_plain_mimetype/;' \\\n\t-e 's/\\bgit_print_page_nav\\b/git_page_nav/;' \\\n\t-e 's/\\bgit_print_header_div\\b/git_header_div/;' \\\n\tgitweb.perl\n\n# end of gitweb-unrename.sh\n+++\nFrom 73aac631709c11d01ac36a1f3f8c8ea3d1591b4d Mon Sep 17 00:00:00 2001\nFrom: Jakub Narebski \nDate: Mon, 7 Aug 2006 15:32:07 +0200\nSubject: [PATCH] gitweb: Great subroutines renaming\n\nRename some of subroutines to better reflect what they do.\nSome renames were not performed because subroutine name\nreflects hash key.\n\nSubroutines name guideline:\n* git_ prefix for subroutines related to git commands,\n or to gitweb actions\n* git_get_ prefix for subroutines calling git command\n and returning some output\n* git_read_ prefix for subroutines directly accessing git\n repository files\n* parse_ prefix for subroutines parsing some text, or reading and\n parsing some text into hash or list\n* format_ prefix for subroutines formatting/post-processing some\n HTML/text fragment\n* _get_ infix for subroutines which return result\n* _print_ infix for subroutines which print fragment of output\n* _body suffix for subroutines which outputs main part (body)\n of related action\n* _nav suffix for subroutines related to navigation bars\n* _div suffix for subroutines returning or ptinting div element\n\nRenames:\n- git_get_referencing => format_mark_referencing\n- git_read_head => git_get_head\n- read_info_ref => git_read_info_refs\n- date_str => parse_date\n- git_read_tag => parse_tag\n- git_read_commit => parse_commit\n- git_blob_plain_mimetype => blob_plain_mimetype\n- git_page_nav => git_print_page_nav\n- git_header_div => git_print_header_div\n\nSigned-off-by: Jakub Narebski \n---\n gitweb/gitweb.perl | 218 ++++++++++++++++++++++++++--------------------------\n 1 files changed, 109 insertions(+), 109 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex b3bfc6b..d8dbd3d 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -362,7 +362,7 @@ sub format_log_line_html {\n }\n \n # format marker of refs pointing to given object\n-sub git_get_referencing {\n+sub format_mark_referencing {\n \tmy ($refs, $id) = @_;\n \n \tif (defined $refs->{$id}) {\n@@ -376,7 +376,7 @@ ## -------------------------------------\n ## git utility subroutines, invoking git commands\n \n # get HEAD ref of given project as hash\n-sub git_read_head {\n+sub git_get_head {\n \tmy $project = shift;\n \tmy $oENV = $ENV{'GIT_DIR'};\n \tmy $retval = undef;\n@@ -511,7 +511,7 @@ sub git_read_projects {\n \treturn @list;\n }\n \n-sub read_info_ref {\n+sub git_read_info_refs {\n \tmy $type = shift || \"\";\n \tmy %refs;\n \t# 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c\trefs/tags/v2.6.11\n@@ -536,7 +536,7 @@ sub read_info_ref {\n ## ----------------------------------------------------------------------\n ## parse to hash functions\n \n-sub date_str {\n+sub parse_date {\n \tmy $epoch = shift;\n \tmy $tz = shift || \"-0000\";\n \n@@ -561,7 +561,7 @@ sub date_str {\n \treturn %date;\n }\n \n-sub git_read_tag {\n+sub parse_tag {\n \tmy $tag_id = shift;\n \tmy %tag;\n \tmy @comment;\n@@ -596,7 +596,7 @@ sub git_read_tag {\n \treturn %tag\n }\n \n-sub git_read_commit {\n+sub parse_commit {\n \tmy $commit_id = shift;\n \tmy $commit_text = shift;\n \n@@ -716,10 +716,10 @@ sub git_read_refs {\n \t\t$ref_item{'epoch'} = 0;\n \t\t$ref_item{'age'} = \"unknown\";\n \t\tif ($type eq \"tag\") {\n-\t\t\tmy %tag = git_read_tag($ref_id);\n+\t\t\tmy %tag = parse_tag($ref_id);\n \t\t\t$ref_item{'comment'} = $tag{'comment'};\n \t\t\tif ($tag{'type'} eq \"commit\") {\n-\t\t\t\t%co = git_read_commit($tag{'object'});\n+\t\t\t\t%co = parse_commit($tag{'object'});\n \t\t\t\t$ref_item{'epoch'} = $co{'committer_epoch'};\n \t\t\t\t$ref_item{'age'} = $co{'age_string'};\n \t\t\t} elsif (defined($tag{'epoch'})) {\n@@ -731,7 +731,7 @@ sub git_read_refs {\n \t\t\t$ref_item{'name'} = $tag{'name'};\n \t\t\t$ref_item{'refid'} = $tag{'object'};\n \t\t} elsif ($type eq \"commit\"){\n-\t\t\t%co = git_read_commit($ref_id);\n+\t\t\t%co = parse_commit($ref_id);\n \t\t\t$ref_item{'reftype'} = \"commit\";\n \t\t\t$ref_item{'name'} = $ref_file;\n \t\t\t$ref_item{'title'} = $co{'title'};\n@@ -806,7 +806,7 @@ sub mimetype_guess {\n \treturn $mime;\n }\n \n-sub git_blob_plain_mimetype {\n+sub blob_plain_mimetype {\n \tmy $fd = shift;\n \tmy $filename = shift;\n \n@@ -955,7 +955,7 @@ sub die_error {\n ## ----------------------------------------------------------------------\n ## functions printing or outputting HTML: navigation\n \n-sub git_page_nav {\n+sub git_print_page_nav {\n \tmy ($current, $suppress, $head, $treehead, $treebase, $extra) = @_;\n \t$extra = '' if !defined $extra; # pager or formats\n \n@@ -1022,7 +1022,7 @@ sub git_get_paging_nav {\n ## ......................................................................\n ## functions printing or outputting HTML: div\n \n-sub git_header_div {\n+sub git_print_header_div {\n \tmy ($action, $title, $hash, $hash_base) = @_;\n \tmy $rest = '';\n \n@@ -1062,10 +1062,10 @@ sub git_shortlog_body {\n \tmy $alternate = 0;\n \tfor (my $i = $from; $i <= $to; $i++) {\n \t\tmy $commit = $revlist->[$i];\n-\t\t#my $ref = defined $refs ? git_get_referencing($refs, $commit) : '';\n-\t\tmy $ref = git_get_referencing($refs, $commit);\n-\t\tmy %co = git_read_commit($commit);\n-\t\tmy %ad = date_str($co{'author_epoch'});\n+\t\t#my $ref = defined $refs ? format_mark_referencing($refs, $commit) : '';\n+\t\tmy $ref = format_mark_referencing($refs, $commit);\n+\t\tmy %co = parse_commit($commit);\n+\t\tmy %ad = parse_date($co{'author_epoch'});\n \t\tif ($alternate) {\n \t\t\tprint \"\\n\";\n \t\t} else {\n@@ -1289,12 +1289,12 @@ sub git_project_list {\n \t\tdie_error(undef, \"No projects found\");\n \t}\n \tforeach my $pr (@list) {\n-\t\tmy $head = git_read_head($pr->{'path'});\n+\t\tmy $head = git_get_head($pr->{'path'});\n \t\tif (!defined $head) {\n \t\t\tnext;\n \t\t}\n \t\t$ENV{'GIT_DIR'} = \"$projectroot/$pr->{'path'}\";\n-\t\tmy %co = git_read_commit($head);\n+\t\tmy %co = parse_commit($head);\n \t\tif (!%co) {\n \t\t\tnext;\n \t\t}\n@@ -1385,9 +1385,9 @@ sub git_project_list {\n \n sub git_summary {\n \tmy $descr = git_read_description($project) || \"none\";\n-\tmy $head = git_read_head($project);\n-\tmy %co = git_read_commit($head);\n-\tmy %cd = date_str($co{'committer_epoch'}, $co{'committer_tz'});\n+\tmy $head = git_get_head($project);\n+\tmy %co = parse_commit($head);\n+\tmy %cd = parse_date($co{'committer_epoch'}, $co{'committer_tz'});\n \n \tmy $owner;\n \tif (-f $projects_list) {\n@@ -1408,9 +1408,9 @@ sub git_summary {\n \t\t$owner = get_file_owner(\"$projectroot/$project\");\n \t}\n \n-\tmy $refs = read_info_ref();\n+\tmy $refs = git_read_info_refs();\n \tgit_header_html();\n-\tgit_page_nav('summary','', $head);\n+\tgit_print_page_nav('summary','', $head);\n \n \tprint \"
 
\\n\";\n \tprint \"\\n\" .\n@@ -1419,24 +1419,24 @@ sub git_summary {\n \t \"\\n\" .\n \t \"
last change$cd{'rfc2822'}
\\n\";\n \n-\topen my $fd, \"-|\", $GIT, \"rev-list\", \"--max-count=17\", git_read_head($project)\n+\topen my $fd, \"-|\", $GIT, \"rev-list\", \"--max-count=17\", git_get_head($project)\n \t\tor die_error(undef, \"Open git-rev-list failed\");\n \tmy @revlist = map { chomp; $_ } <$fd>;\n \tclose $fd;\n-\tgit_header_div('shortlog');\n+\tgit_print_header_div('shortlog');\n \tgit_shortlog_body(\\@revlist, 0, 15, $refs,\n \t $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=shortlog\")}, \"...\"));\n \n \tmy $taglist = git_read_refs(\"refs/tags\");\n \tif (defined @$taglist) {\n-\t\tgit_header_div('tags');\n+\t\tgit_print_header_div('tags');\n \t\tgit_tags_body($taglist, 0, 15,\n \t\t $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=tags\")}, \"...\"));\n \t}\n \n \tmy $headlist = git_read_refs(\"refs/heads\");\n \tif (defined @$headlist) {\n-\t\tgit_header_div('heads');\n+\t\tgit_print_header_div('heads');\n \t\tgit_heads_body($headlist, $head, 0, 15,\n \t\t $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=heads\")}, \"...\"));\n \t}\n@@ -1445,11 +1445,11 @@ sub git_summary {\n }\n \n sub git_tag {\n-\tmy $head = git_read_head($project);\n+\tmy $head = git_get_head($project);\n \tgit_header_html();\n-\tgit_page_nav('','', $head,undef,$head);\n-\tmy %tag = git_read_tag($hash);\n-\tgit_header_div('commit', esc_html($tag{'name'}), $hash);\n+\tgit_print_page_nav('','', $head,undef,$head);\n+\tmy %tag = parse_tag($hash);\n+\tgit_print_header_div('commit', esc_html($tag{'name'}), $hash);\n \tprint \"
\\n\" .\n \t \"\\n\" .\n \t \"\\n\" .\n@@ -1458,7 +1458,7 @@ sub git_tag {\n \t \"\\n\" .\n \t \"\\n\";\n \tif (defined($tag{'author'})) {\n-\t\tmy %ad = date_str($tag{'epoch'}, $tag{'tz'});\n+\t\tmy %ad = parse_date($tag{'epoch'}, $tag{'tz'});\n \t\tprint \"\\n\";\n \t\tprint \"\\n\";\n \t}\n@@ -1478,9 +1478,9 @@ sub git_blame2 {\n \tmy $ftype;\n \tdie_error(undef, \"Permission denied\") if (!git_get_project_config_bool ('blame'));\n \tdie_error('404 Not Found', \"File name not defined\") if (!$file_name);\n-\t$hash_base ||= git_read_head($project);\n+\t$hash_base ||= git_get_head($project);\n \tdie_error(undef, \"Couldn't find base commit\") unless ($hash_base);\n-\tmy %co = git_read_commit($hash_base)\n+\tmy %co = parse_commit($hash_base)\n \t\tor die_error(undef, \"Reading commit failed\");\n \tif (!defined $hash) {\n \t\t$hash = git_get_hash_by_path($hash_base, $file_name, \"blob\")\n@@ -1496,8 +1496,8 @@ sub git_blame2 {\n \tmy $formats_nav =\n \t\t$cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blob;h=$hash;hb=$hash_base;f=$file_name\")}, \"blob\") .\n \t\t\" | \" . $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blame;f=$file_name\")}, \"head\");\n-\tgit_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);\n-\tgit_header_div('commit', esc_html($co{'title'}), $hash_base);\n+\tgit_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);\n+\tgit_print_header_div('commit', esc_html($co{'title'}), $hash_base);\n \tgit_print_page_path($file_name, $ftype);\n \tmy @rev_color = (qw(light dark));\n \tmy $num_colors = scalar(@rev_color);\n@@ -1536,9 +1536,9 @@ sub git_blame {\n \tmy $fd;\n \tdie_error('403 Permission denied', \"Permission denied\") if (!git_get_project_config_bool ('blame'));\n \tdie_error('404 Not Found', \"File name not defined\") if (!$file_name);\n-\t$hash_base ||= git_read_head($project);\n+\t$hash_base ||= git_get_head($project);\n \tdie_error(undef, \"Couldn't find base commit\") unless ($hash_base);\n-\tmy %co = git_read_commit($hash_base)\n+\tmy %co = parse_commit($hash_base)\n \t\tor die_error(undef, \"Reading commit failed\");\n \tif (!defined $hash) {\n \t\t$hash = git_get_hash_by_path($hash_base, $file_name, \"blob\")\n@@ -1550,8 +1550,8 @@ sub git_blame {\n \tmy $formats_nav =\n \t\t$cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blob;h=$hash;hb=$hash_base;f=$file_name\")}, \"blob\") .\n \t\t\" | \" . $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blame;f=$file_name\")}, \"head\");\n-\tgit_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);\n-\tgit_header_div('commit', esc_html($co{'title'}), $hash_base);\n+\tgit_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);\n+\tgit_print_header_div('commit', esc_html($co{'title'}), $hash_base);\n \tgit_print_page_path($file_name, 'blob');\n \tprint \"
\\n\";\n \tprint <a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blame;h=$hash;hb=$hash_base;f=$file_name\")}, \"blame\") . \" | \";\n@@ -1709,8 +1709,8 @@ sub git_blob {\n \t\t} else {\n \t\t\t$formats_nav .= $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blob_plain;h=$hash\")}, \"plain\");\n \t\t}\n-\t\tgit_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);\n-\t\tgit_header_div('commit', esc_html($co{'title'}), $hash_base);\n+\t\tgit_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);\n+\t\tgit_print_header_div('commit', esc_html($co{'title'}), $hash_base);\n \t} else {\n \t\tprint \"
\\n\" .\n \t\t \"

\\n\" .\n@@ -1732,7 +1732,7 @@ sub git_blob {\n \n sub git_tree {\n \tif (!defined $hash) {\n-\t\t$hash = git_read_head($project);\n+\t\t$hash = git_get_head($project);\n \t\tif (defined $file_name) {\n \t\t\tmy $base = $hash_base || $hash;\n \t\t\t$hash = git_get_hash_by_path($base, $file_name, \"tree\");\n@@ -1748,16 +1748,16 @@ sub git_tree {\n \tclose $fd or die_error(undef, \"Reading tree failed\");\n \t$/ = \"\\n\";\n \n-\tmy $refs = read_info_ref();\n-\tmy $ref = git_get_referencing($refs, $hash_base);\n+\tmy $refs = git_read_info_refs();\n+\tmy $ref = format_mark_referencing($refs, $hash_base);\n \tgit_header_html();\n \tmy $base_key = \"\";\n \tmy $base = \"\";\n \tmy $have_blame = git_get_project_config_bool ('blame');\n-\tif (defined $hash_base && (my %co = git_read_commit($hash_base))) {\n+\tif (defined $hash_base && (my %co = parse_commit($hash_base))) {\n \t\t$base_key = \";hb=$hash_base\";\n-\t\tgit_page_nav('tree','', $hash_base);\n-\t\tgit_header_div('commit', esc_html($co{'title'}) . $ref, $hash_base);\n+\t\tgit_print_page_nav('tree','', $hash_base);\n+\t\tgit_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash_base);\n \t} else {\n \t\tprint \"
\\n\";\n \t\tprint \"

\\n\";\n@@ -1813,14 +1813,14 @@ sub git_tree {\n }\n \n sub git_log {\n-\tmy $head = git_read_head($project);\n+\tmy $head = git_get_head($project);\n \tif (!defined $hash) {\n \t\t$hash = $head;\n \t}\n \tif (!defined $page) {\n \t\t$page = 0;\n \t}\n-\tmy $refs = read_info_ref();\n+\tmy $refs = git_read_info_refs();\n \n \tmy $limit = sprintf(\"--max-count=%i\", (100 * ($page+1)));\n \topen my $fd, \"-|\", $GIT, \"rev-list\", $limit, $hash\n@@ -1831,21 +1831,21 @@ sub git_log {\n \tmy $paging_nav = git_get_paging_nav('log', $hash, $head, $page, $#revlist);\n \n \tgit_header_html();\n-\tgit_page_nav('log','', $hash,undef,undef, $paging_nav);\n+\tgit_print_page_nav('log','', $hash,undef,undef, $paging_nav);\n \n \tif (!@revlist) {\n-\t\tmy %co = git_read_commit($hash);\n+\t\tmy %co = parse_commit($hash);\n \n-\t\tgit_header_div('summary', $project);\n+\t\tgit_print_header_div('summary', $project);\n \t\tprint \"
Last change $co{'age_string'}.

\\n\";\n \t}\n \tfor (my $i = ($page * 100); $i <= $#revlist; $i++) {\n \t\tmy $commit = $revlist[$i];\n-\t\tmy $ref = git_get_referencing($refs, $commit);\n-\t\tmy %co = git_read_commit($commit);\n+\t\tmy $ref = format_mark_referencing($refs, $commit);\n+\t\tmy %co = parse_commit($commit);\n \t\tnext if !%co;\n-\t\tmy %ad = date_str($co{'author_epoch'});\n-\t\tgit_header_div('commit',\n+\t\tmy %ad = parse_date($co{'author_epoch'});\n+\t\tgit_print_header_div('commit',\n \t\t\t\t\t\t\t\t\t \"$co{'age_string'}\" .\n \t\t\t\t\t\t\t\t\t esc_html($co{'title'}) . $ref,\n \t\t\t\t\t\t\t\t\t $commit);\n@@ -1883,12 +1883,12 @@ sub git_log {\n }\n \n sub git_commit {\n-\tmy %co = git_read_commit($hash);\n+\tmy %co = parse_commit($hash);\n \tif (!%co) {\n \t\tdie_error(undef, \"Unknown commit object\");\n \t}\n-\tmy %ad = date_str($co{'author_epoch'}, $co{'author_tz'});\n-\tmy %cd = date_str($co{'committer_epoch'}, $co{'committer_tz'});\n+\tmy %ad = parse_date($co{'author_epoch'}, $co{'author_tz'});\n+\tmy %cd = parse_date($co{'committer_epoch'}, $co{'committer_tz'});\n \n \tmy $parent = $co{'parent'};\n \tif (!defined $parent) {\n@@ -1904,22 +1904,22 @@ sub git_commit {\n \tif ($hash =~ m/^[0-9a-fA-F]{40}$/) {\n \t\t$expires = \"+1d\";\n \t}\n-\tmy $refs = read_info_ref();\n-\tmy $ref = git_get_referencing($refs, $co{'id'});\n+\tmy $refs = git_read_info_refs();\n+\tmy $ref = format_mark_referencing($refs, $co{'id'});\n \tmy $formats_nav = '';\n \tif (defined $file_name && defined $co{'parent'}) {\n \t\tmy $parent = $co{'parent'};\n \t\t$formats_nav .= $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blame;hb=$parent;f=$file_name\")}, \"blame\");\n \t}\n \tgit_header_html(undef, $expires);\n-\tgit_page_nav('commit', defined $co{'parent'} ? '' : 'commitdiff',\n+\tgit_print_page_nav('commit', defined $co{'parent'} ? '' : 'commitdiff',\n \t\t\t\t\t\t\t $hash, $co{'tree'}, $hash,\n \t\t\t\t\t\t\t $formats_nav);\n \n \tif (defined $co{'parent'}) {\n-\t\tgit_header_div('commitdiff', esc_html($co{'title'}) . $ref, $hash);\n+\t\tgit_print_header_div('commitdiff', esc_html($co{'title'}) . $ref, $hash);\n \t} else {\n-\t\tgit_header_div('tree', esc_html($co{'title'}) . $ref, $co{'tree'}, $hash);\n+\t\tgit_print_header_div('tree', esc_html($co{'title'}) . $ref, $co{'tree'}, $hash);\n \t}\n \tprint \"
\\n\" .\n \t \"
\" . $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=$tag{'type'};h=$tag{'object'}\")}, $tag{'type'}) . \"
author\" . esc_html($tag{'author'}) . \"
\" . $ad{'rfc2822'} . sprintf(\" (%02d:%02d %s)\", $ad{'hour_local'}, $ad{'minute_local'}, $ad{'tz_local'}) . \"
\\n\";\n@@ -2081,11 +2081,11 @@ sub git_commit {\n sub git_blobdiff {\n \tmkdir($git_temp, 0700);\n \tgit_header_html();\n-\tif (defined $hash_base && (my %co = git_read_commit($hash_base))) {\n+\tif (defined $hash_base && (my %co = parse_commit($hash_base))) {\n \t\tmy $formats_nav =\n \t\t\t$cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blobdiff_plain;h=$hash;hp=$hash_parent\")}, \"plain\");\n-\t\tgit_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);\n-\t\tgit_header_div('commit', esc_html($co{'title'}), $hash_base);\n+\t\tgit_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);\n+\t\tgit_print_header_div('commit', esc_html($co{'title'}), $hash_base);\n \t} else {\n \t\tprint \"
\\n\" .\n \t\t \"

\\n\" .\n@@ -2111,7 +2111,7 @@ sub git_blobdiff_plain {\n \n sub git_commitdiff {\n \tmkdir($git_temp, 0700);\n-\tmy %co = git_read_commit($hash);\n+\tmy %co = parse_commit($hash);\n \tif (!%co) {\n \t\tdie_error(undef, \"Unknown commit object\");\n \t}\n@@ -2128,13 +2128,13 @@ sub git_commitdiff {\n \tif ($hash =~ m/^[0-9a-fA-F]{40}$/) {\n \t\t$expires = \"+1d\";\n \t}\n-\tmy $refs = read_info_ref();\n-\tmy $ref = git_get_referencing($refs, $co{'id'});\n+\tmy $refs = git_read_info_refs();\n+\tmy $ref = format_mark_referencing($refs, $co{'id'});\n \tmy $formats_nav =\n \t\t$cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=commitdiff_plain;h=$hash;hp=$hash_parent\")}, \"plain\");\n \tgit_header_html(undef, $expires);\n-\tgit_page_nav('commitdiff','', $hash,$co{'tree'},$hash, $formats_nav);\n-\tgit_header_div('commit', esc_html($co{'title'}) . $ref, $hash);\n+\tgit_print_page_nav('commitdiff','', $hash,$co{'tree'},$hash, $formats_nav);\n+\tgit_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash);\n \tprint \"
\\n\";\n \tmy $comment = $co{'comment'};\n \tmy $empty = 0;\n@@ -2200,7 +2200,7 @@ sub git_commitdiff {\n \n sub git_commitdiff_plain {\n \tmkdir($git_temp, 0700);\n-\tmy %co = git_read_commit($hash);\n+\tmy %co = parse_commit($hash);\n \tif (!%co) {\n \t\tdie_error(undef, \"Unknown commit object\");\n \t}\n@@ -2214,7 +2214,7 @@ sub git_commitdiff_plain {\n \n \t# try to figure out the next tag after this commit\n \tmy $tagname;\n-\tmy $refs = read_info_ref(\"tags\");\n+\tmy $refs = git_read_info_refs(\"tags\");\n \topen $fd, \"-|\", $GIT, \"rev-list\", \"HEAD\";\n \tmy @commits = map { chomp; $_ } <$fd>;\n \tclose $fd;\n@@ -2228,7 +2228,7 @@ sub git_commitdiff_plain {\n \t}\n \n \tprint $cgi->header(-type => \"text/plain\", -charset => 'utf-8', '-content-disposition' => \"inline; filename=\\\"git-$hash.patch\\\"\");\n-\tmy %ad = date_str($co{'author_epoch'}, $co{'author_tz'});\n+\tmy %ad = parse_date($co{'author_epoch'}, $co{'author_tz'});\n \tmy $comment = $co{'comment'};\n \tprint \"From: $co{'author'}\\n\" .\n \t \"Date: $ad{'rfc2822'} ($ad{'tz_local'})\\n\".\n@@ -2264,17 +2264,17 @@ sub git_commitdiff_plain {\n \n sub git_history {\n \tif (!defined $hash_base) {\n-\t\t$hash_base = git_read_head($project);\n+\t\t$hash_base = git_get_head($project);\n \t}\n \tmy $ftype;\n-\tmy %co = git_read_commit($hash_base);\n+\tmy %co = parse_commit($hash_base);\n \tif (!%co) {\n \t\tdie_error(undef, \"Unknown commit object\");\n \t}\n-\tmy $refs = read_info_ref();\n+\tmy $refs = git_read_info_refs();\n \tgit_header_html();\n-\tgit_page_nav('','', $hash_base,$co{'tree'},$hash_base);\n-\tgit_header_div('commit', esc_html($co{'title'}), $hash_base);\n+\tgit_print_page_nav('','', $hash_base,$co{'tree'},$hash_base);\n+\tgit_print_header_div('commit', esc_html($co{'title'}), $hash_base);\n \tif (!defined $hash && defined $file_name) {\n \t\t$hash = git_get_hash_by_path($hash_base, $file_name);\n \t}\n@@ -2290,11 +2290,11 @@ sub git_history {\n \twhile (my $line = <$fd>) {\n \t\tif ($line =~ m/^([0-9a-fA-F]{40})/){\n \t\t\tmy $commit = $1;\n-\t\t\tmy %co = git_read_commit($commit);\n+\t\t\tmy %co = parse_commit($commit);\n \t\t\tif (!%co) {\n \t\t\t\tnext;\n \t\t\t}\n-\t\t\tmy $ref = git_get_referencing($refs, $commit);\n+\t\t\tmy $ref = format_mark_referencing($refs, $commit);\n \t\t\tif ($alternate) {\n \t\t\t\tprint \"
\\n\";\n \t\t\t} else {\n@@ -2330,9 +2330,9 @@ sub git_search {\n \t\tdie_error(undef, \"Text field empty\");\n \t}\n \tif (!defined $hash) {\n-\t\t$hash = git_read_head($project);\n+\t\t$hash = git_get_head($project);\n \t}\n-\tmy %co = git_read_commit($hash);\n+\tmy %co = parse_commit($hash);\n \tif (!%co) {\n \t\tdie_error(undef, \"Unknown commit object\");\n \t}\n@@ -2351,8 +2351,8 @@ sub git_search {\n \t\t$pickaxe_search = 1;\n \t}\n \tgit_header_html();\n-\tgit_page_nav('','', $hash,$co{'tree'},$hash);\n-\tgit_header_div('commit', esc_html($co{'title'}), $hash);\n+\tgit_print_page_nav('','', $hash,$co{'tree'},$hash);\n+\tgit_print_header_div('commit', esc_html($co{'title'}), $hash);\n \n \tprint \"
\\n\";\n \tmy $alternate = 0;\n@@ -2370,7 +2370,7 @@ sub git_search {\n \t\t\t\tnext;\n \t\t\t}\n \t\t\tmy @commit_lines = split \"\\n\", $commit_text;\n-\t\t\tmy %co = git_read_commit(undef, \\@commit_lines);\n+\t\t\tmy %co = parse_commit(undef, \\@commit_lines);\n \t\t\tif (!%co) {\n \t\t\t\tnext;\n \t\t\t}\n@@ -2451,7 +2451,7 @@ sub git_search {\n \t\t\t\t\tprint \"\\n\" .\n \t\t\t\t\t \"\\n\";\n \t\t\t\t}\n-\t\t\t\t%co = git_read_commit($1);\n+\t\t\t\t%co = parse_commit($1);\n \t\t\t}\n \t\t}\n \t\tclose $fd;\n@@ -2461,14 +2461,14 @@ sub git_search {\n }\n \n sub git_shortlog {\n-\tmy $head = git_read_head($project);\n+\tmy $head = git_get_head($project);\n \tif (!defined $hash) {\n \t\t$hash = $head;\n \t}\n \tif (!defined $page) {\n \t\t$page = 0;\n \t}\n-\tmy $refs = read_info_ref();\n+\tmy $refs = git_read_info_refs();\n \n \tmy $limit = sprintf(\"--max-count=%i\", (100 * ($page+1)));\n \topen my $fd, \"-|\", $GIT, \"rev-list\", $limit, $hash\n@@ -2486,8 +2486,8 @@ sub git_shortlog {\n \n \n \tgit_header_html();\n-\tgit_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);\n-\tgit_header_div('summary', $project);\n+\tgit_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);\n+\tgit_print_header_div('summary', $project);\n \n \tgit_shortlog_body(\\@revlist, ($page * 100), $#revlist, $refs, $next_link);\n \n@@ -2499,7 +2499,7 @@ ## feeds (RSS, OPML)\n \n sub git_rss {\n \t# http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ\n-\topen my $fd, \"-|\", $GIT, \"rev-list\", \"--max-count=150\", git_read_head($project)\n+\topen my $fd, \"-|\", $GIT, \"rev-list\", \"--max-count=150\", git_get_head($project)\n \t\tor die_error(undef, \"Open git-rev-list failed\");\n \tmy @revlist = map { chomp; $_ } <$fd>;\n \tclose $fd or die_error(undef, \"Reading git-rev-list failed\");\n@@ -2514,12 +2514,12 @@ sub git_rss {\n \n \tfor (my $i = 0; $i <= $#revlist; $i++) {\n \t\tmy $commit = $revlist[$i];\n-\t\tmy %co = git_read_commit($commit);\n+\t\tmy %co = parse_commit($commit);\n \t\t# we read 150, we always show 30 and the ones more recent than 48 hours\n \t\tif (($i >= 20) && ((time - $co{'committer_epoch'}) > 48*60*60)) {\n \t\t\tlast;\n \t\t}\n-\t\tmy %cd = date_str($co{'committer_epoch'});\n+\t\tmy %cd = parse_date($co{'committer_epoch'});\n \t\topen $fd, \"-|\", $GIT, \"diff-tree\", '-r', $co{'parent'}, $co{'id'} or next;\n \t\tmy @difftree = map { chomp; $_ } <$fd>;\n \t\tclose $fd or next;\n@@ -2569,12 +2569,12 @@ sub git_opml {\n \n \tforeach my $pr (@list) {\n \t\tmy %proj = %$pr;\n-\t\tmy $head = git_read_head($proj{'path'});\n+\t\tmy $head = git_get_head($proj{'path'});\n \t\tif (!defined $head) {\n \t\t\tnext;\n \t\t}\n \t\t$ENV{'GIT_DIR'} = \"$projectroot/$proj{'path'}\";\n-\t\tmy %co = git_read_commit($head);\n+\t\tmy %co = parse_commit($head);\n \t\tif (!%co) {\n \t\t\tnext;\n \t\t}\n-- \n1.4.1.1\n"},{"id":"24941","messageId":"7v3bc82v7l.fsf@assigned-by-dhcp.cox.net","threadId":"5163","inReplyTo":"200608071626.52655.jnareb@gmail.com","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-07T19:37:34Z","receivedAt":"2006-08-07T19:37:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> This RFC is about better naming of subroutines in gitweb. The patch was\n> generated on top of 'next' (7c7e45d0cc0f482aeb19ecb0b56e9e7b65472c56)\n> using embedded gitweb-rename.sh script.\n\n> Subroutines name guideline:\n> * git_ prefix for subroutines related to git commands,\n> or to gitweb actions\n> * git_get_ prefix for subroutines calling git command\n> and returning some output\n> * git_read_ prefix for subroutines directly accessing git\n> repository files\n\n - (I am not complaining or objecting yet -- this is just an\n observation. ) The distinction between git_get_foo and\n git_read_foo is an implementation detail. The latter could\n signal that the implementation bypasses the published\n interface but depends on the implementation detail of the\n low-level git, so it might be a good idea, but on the other\n hand the only instance is git_read_info_refs which reads from\n .git/info/refs -- and its format is part of the published\n interface -- so I am not so sure this distinction is worth\n it. And certainly we would not want to rely too heavily on\n the current implementation of the low-level git, so we\n obviously do not want to add more git_read_foo's needlessly,\n which makes me feel even less sure if we would want\n git_read_foo...\n\n> * parse_ prefix for subroutines parsing some text, or reading and\n> parsing some text into hash or list\n> * format_ prefix for subroutines formatting/post-processing some\n> HTML/text fragment\n> * _get_ infix for subroutines which return result\n> * _print_ infix for subroutines which print fragment of output\n> * _body suffix for subroutines which outputs main part (body)\n> of related action\n> * _nav suffix for subroutines related to navigation bars\n> * _div suffix for subroutines returning or ptinting div element\n\n - All of these sound sane. \n\n> How should subroutines be named? Do you agree with proposal, or not?\n\nI suspect that the list may disagree with some minor details on\nthe naming guidelines but I hope that everybody would in\nprinciple be in favor of this.\n\n> Is such renaming usefull?\n\nIf we are to have many more fixes and clean-ups on gitweb,\nreadable and consistent names would be very helpful.\n\nThe problem is when. If we are going to apply this, we need to\npick a point of time when not many patches on gitweb are in\nflight; otherwise I'd end up asking people to resend using new\nnames.\n"},{"id":"24951","messageId":"eb8cdh$s6n$1@sea.gmane.org","threadId":"5163","inReplyTo":"7v3bc82v7l.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-07T21:47:37Z","receivedAt":"2006-08-07T21:47:37Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n>> This RFC is about better naming of subroutines in gitweb. The patch was\n>> generated on top of 'next' (7c7e45d0cc0f482aeb19ecb0b56e9e7b65472c56)\n>> using embedded gitweb-rename.sh script.\n[...]\n>> * git_read_ prefix for subroutines directly accessing git\n>> repository files\n> \n> - (I am not complaining or objecting yet -- this is just an\n> observation. ) The distinction between git_get_foo and\n> git_read_foo is an implementation detail. The latter could\n> signal that the implementation bypasses the published\n> interface but depends on the implementation detail of the\n> low-level git, so it might be a good idea, but on the other\n> hand the only instance is git_read_info_refs which reads from\n> .git/info/refs -- and its format is part of the published\n> interface -- so I am not so sure this distinction is worth\n> it. And certainly we would not want to rely too heavily on\n> the current implementation of the low-level git, so we\n> obviously do not want to add more git_read_foo's needlessly,\n> which makes me feel even less sure if we would want\n> git_read_foo...\n\nCurrently after rename we have the following git_read_* functions\n\n* git_read_info_refs, which reads .git/info/refs directly and relies on it's\nformat\n* git_read_hash which translates ref to hash by reading ref file\n(e.g. .git/refs/heads/master) which means that it doesn't support symrefs\nyet; but first, it should be easy to implement without invoking any git\ncommand, and second, there are usually no symrefs beside HEAD, and I'm not\nsure that git would work with non-HEAD symref.\n* git_read_refs (or rather git_readdir_refs) which reads .git/refs directory\n* git_read_projects (or rather git_readdir_projects) which checks for\nprojects checking if HEAD file exists\n* git_read_description which reads .git/description; but in the future\ndescription might be stored in repository config\n\nWhat is also important is the fast that git_read_* functions are fast,\nwith exception of git_read_info_refs...\n\n[...]\n> If we are to have many more fixes and clean-ups on gitweb,\n> readable and consistent names would be very helpful.\n> \n> The problem is when. If we are going to apply this, we need to\n> pick a point of time when not many patches on gitweb are in\n> flight; otherwise I'd end up asking people to resend using new\n> names.\n\nWith two scripts attached to the first post in this thread it would be\nsimple to apply pre-rename patch, by converting gitweb to pre-rename using\ngitweb-unrename.sh script, then applying patch, then restoring new names\nusing gitweb-rename.sh script, and finally comitting changes (or amending\ncommit).\n\nBut I agree that it would be best to do \"subroutine renaming\" during lull in\ngitweb development.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"24952","messageId":"eb8cn4$u5b$1@sea.gmane.org","threadId":"5163","inReplyTo":"eb8cdh$s6n$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-07T21:52:43Z","receivedAt":"2006-08-07T21:52:43Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> What is also important is the fast that git_read_* functions are fast,\n> with exception of git_read_info_refs...\n\nI meant git_read_refs, which also does refs parsing, which is needed only to\nget epoch information to sort refs by epoch, and discard most of them. This\nmakes summary and tags slow, so matled proposed caching (or extending\ninfo/refs, or making equivalent of info/refs) this information on #git.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"24953","messageId":"7v4pwo1a0r.fsf@assigned-by-dhcp.cox.net","threadId":"5163","inReplyTo":"eb8cdh$s6n$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-07T22:00:36Z","receivedAt":"2006-08-07T22:00:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Currently after rename we have the following git_read_* functions\n>\n> * git_read_info_refs, which reads .git/info/refs directly and relies on it's\n> format\n> * git_read_hash which translates ref to hash by reading ref file\n> (e.g. .git/refs/heads/master) which means that it doesn't support symrefs\n> yet; but first, it should be easy to implement without invoking any git\n> command, and second, there are usually no symrefs beside HEAD, and I'm not\n> sure that git would work with non-HEAD symref.\n> * git_read_refs (or rather git_readdir_refs) which reads .git/refs directory\n> * git_read_projects (or rather git_readdir_projects) which checks for\n> projects checking if HEAD file exists\n> * git_read_description which reads .git/description; but in the future\n> description might be stored in repository config\n>\n> What is also important is the fast that git_read_* functions are fast,\n> with exception of git_read_info_refs...\n\nHmph. readdir-refs is quite bad for future compatibility, so is\nread_hash.\n\nIf you want _fast_ then make the implementation fast (or leave\nroom to make it fast later); encoding the fastness assumption in\nthe name IS WRONG.\n\nFor example, sub git_get_hash (not git_read_hash) can stay as\n(potentially buggy wrt symrefs) \"reading from .git/refs/$thing\"\nor could even be fixed to read from git-rev-parse (which is the\nkosher way). If it turns out to be a bottleneck, it could be\nrewritten using Git.xs. The same thing for read_refs which I\nthink should be doing ls-remote on the repository if it wants to\nbe kosher.\n\n>> The problem is when...\n>\n> With two scripts attached to the first post in this thread it would be\n> simple to apply pre-rename patch, by converting gitweb to pre-rename using\n> gitweb-unrename.sh script, then applying patch, then restoring new names\n> using gitweb-rename.sh script, and finally comitting changes (or amending\n> commit).\n\nThat assumes the rename be done now, and nobody introduces new\nfunctions following old naming convention in the meantime.\n"},{"id":"24955","messageId":"eb8e12$2aa$1@sea.gmane.org","threadId":"5163","inReplyTo":"7v4pwo1a0r.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-07T22:15:05Z","receivedAt":"2006-08-07T22:15:05Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes: \n\n>> What is also important is the fast that git_read_* functions are fast,\n>> with exception of git_read_info_refs...\n> \n> Hmph. readdir-refs is quite bad for future compatibility, so is\n> read_hash.\n\nFast = doesn't call git commands, so no delay for fork+exec.\n\n> If you want _fast_ then make the implementation fast (or leave\n> room to make it fast later); encoding the fastness assumption in\n> the name IS WRONG.\n\nMatthias Lederhofer has noticed that parsing all the tags in \"summary\" and\n\"tags\" views, while we use only epoch/timestamp information to sort them\nand discard most of parsed input, is bottleneck due to the fact that\nusually number of tags is linear with history (version tags) and the fact\nthat for each tag is one invocation of git (one fork, two execs).\n\n> For example, sub git_get_hash (not git_read_hash) can stay as\n> (potentially buggy wrt symrefs) \"reading from .git/refs/$thing\"\n> or could even be fixed to read from git-rev-parse (which is the\n> kosher way). If it turns out to be a bottleneck, it could be\n> rewritten using Git.xs. The same thing for read_refs which I\n> think should be doing ls-remote on the repository if it wants to\n> be kosher.\n\nTrue. So _read_ based on actually reading the files is out.\ngit_get_hash_by_ref, git_get_HEAD_hash (or just git_get_ref, git_get_head)\nreturn single scalar value; git_read_info_refs and git_read_refs return\nreference to hash or array, while git_read_projects returns array.\n\nSo the new guidelines would be:\n* git_get_ prefix for subroutines related to git repository\n and returning single scalar (single value).\n* git_read_ prefix for subroutines related to git repository, reading some\n files or multiline output, and returning hash reference, or list\n reference, or list.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"24960","messageId":"eb8gio$8i7$1@sea.gmane.org","threadId":"5163","inReplyTo":"eb8e12$2aa$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-07T22:58:40Z","receivedAt":"2006-08-07T22:58:40Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> True. So _read_ based on actually reading the files is out.\n> git_get_hash_by_ref, git_get_HEAD_hash (or just git_get_ref, git_get_head)\nOr git_get_hash, git_get_head_hash\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"24964","messageId":"7vejvsyum8.fsf@assigned-by-dhcp.cox.net","threadId":"5163","inReplyTo":"eb8e12$2aa$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-07T23:49:19Z","receivedAt":"2006-08-07T23:49:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Matthias Lederhofer has noticed that parsing all the tags in \"summary\" and\n> \"tags\" views, while we use only epoch/timestamp information to sort them\n> and discard most of parsed input, is bottleneck due to the fact that\n> usually number of tags is linear with history (version tags) and the fact\n> that for each tag is one invocation of git (one fork, two execs).\n\nMaybe we would want to expose for_each_ref somehow to the\ncommand level then. Looking at how \"git branch\" without any\nargument lists the branches, and how \"git tag -l\" lists the\ntags, it appears that we could benefit from such a command [*1*].\n\nOf course doing it in Git.xs to make a single C level call is\neasy, but that would benefit only Perl scripts, so it is not a\nvery good general solution.\n\n> So the new guidelines would be:\n> * git_get_ prefix for subroutines related to git repository\n> and returning single scalar (single value).\n> * git_read_ prefix for subroutines related to git repository, reading some\n> files or multiline output, and returning hash reference, or list\n> reference, or list.\n\nI would suggest to use git_get for both, unless there is a good\nreason to differenciate them, since I do not understand why you\nwould want to differenciate one value vs multivalue.\n\n-- >8 -- [*1*] -- >8 --\n[PATCH] git-show-refs\n\nImplementation is left as an exercise ;-)\n\n---\ndiff --git a/Documentation/git-show-refs.txt b/Documentation/git-show-refs.txt\nnew file mode 100644\nindex 0000000..e2869e0\n--- /dev/null\n+++ b/Documentation/git-show-refs.txt\n@@ -0,0 +1,96 @@\n+git-show-refs(1)\n+================\n+\n+NAME\n+----\n+git-show-refs - Lists refs in various formats\n+\n+SYNOPSIS\n+--------\n+'git-show-refs' [--count=] [--sort=] [--format=] []\n+\n+DESCRIPTION\n+-----------\n+\n+Iterate over refs under `$GIT_DIR/refs` that match ``\n+and show them according to the given ``, after sorting\n+them according to the given ``. If `` is given,\n+stop after showing that many refs.\n+\n+OPTIONS\n+-------\n+::\n+\tBy default the command shows all refs that match\n+\t``. This option makes it stop after showing\n+\tthat many refs.\n+\n+::\n+\tComma separated field names to sort on. Prefix `-` to\n+\tsort in descending order of the value. When\n+\tunspecified, `name` is used.\n+\n+::\n+\tA string that interpolates `%(field name)` from the\n+\tobject pointed at by a ref being shown. When\n+\tunspecified, `%(name)` is used.\n+\n+::\n+\tIf given, the name of the ref is matched against this\n+\tusing fnmatch(3). Refs that do not match the pattern\n+\tare not shown.\n+\n+\n+FIELD NAMES\n+-----------\n+\n+Various values from structured fields in referenced objects can\n+be used to interpolate into the resulting output, or as sort\n+keys.\n+\n+For all objects, the following names can be used:\n+\n+name::\n+\tThe name of the ref (the part after $GIT_DIR/refs/),\n+\texcept that when `` is used, the leading fixed\n+\tstring part of `` is stripped out.\n+\n+objecttype::\n+\tThe type of the object (`blob`, `tree`, `commit`, `tag`)\n+\n+objectsize::\n+\tThe size of the object (the same as `git-cat-file -s` reports).\n+\n+objectname::\n+\tThe object name (aka SHA-1).\n+\n+In addition, for commit and tag objects, the header field names\n+(`tree`, `parent`, `object`, `type`, and `tag`) can be used to\n+specify the value in the header field. Fields that have\n+name-email-date tuple as its value (`author`, `committer`, and\n+`tagger`) can be suffixed with `name`, `email`, and `date` to\n+extract the named component. The first line of a commit and tag\n+object can be referred to with `subject`, the remaining lines\n+with `body`, and both (including the typical blank line after\n+`subject`) with `contents`.\n+\n+Also a pseudo field name `ishead` can be used to check if the\n+ref is pointed by `$GIT_DIR/HEAD` pointer. The field\n+interpolates as \"* \" if true, otherwise an empty string.\n+\n+For sorting purposes, fields with numeric values sort in numeric\n+order (`objectsize`, `authordate`, `committerdate`, `taggerdate`).\n+All other fields are used to sort in their byte-value order.\n+\n+\n+EXAMPLES\n+--------\n+\n+Show most recent 16 tags for consumption by gitweb::\n+\tgit-show-refs --count=16 --sort=-taggerdate,name \\\n+\t\t--format='%(taggerdate) %(name)\\t%(tag)\\t%(subject)' 'tags/*'\n+\n+`git-branch` without argument::\n+\tgit-show-refs --format='%(ishead)%(name)' 'heads/*'\n+\n+`git-tag -l`::\n+\tgit-show-refs tags/*\n"},{"id":"24965","messageId":"eb8kph$j6i$1@sea.gmane.org","threadId":"5163","inReplyTo":"7vejvsyum8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-08T00:10:33Z","receivedAt":"2006-08-08T00:10:33Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n\n>> So the new guidelines would be:\n>> * git_get_ prefix for subroutines related to git repository\n>> and returning single scalar (single value).\n>> * git_read_ prefix for subroutines related to git repository, reading some\n>> files or multiline output, and returning hash reference, or list\n>> reference, or list.\n> \n> I would suggest to use git_get for both, unless there is a good\n> reason to differenciate them, since I do not understand why you\n> would want to differenciate one value vs multivalue.\n\nI'd rather have git_read_info_refs, because it _reads_ info/refs file, \nand git_read_refs as opposed to git_get_hash/git_get_ref/git_ref_to_hash\n(or hash_from_ref). I'm not sure about git_read_projects vs. perhaps\ngit_get_project_list or git_list_projects. Neither about \ngit_read_description vs. git_get_project_description\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"24971","messageId":"eb9m30$3ef$2@sea.gmane.org","threadId":"5163","inReplyTo":"7vejvsyum8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-08T09:38:50Z","receivedAt":"2006-08-08T09:38:50Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> +git-show-refs(1)\n> +================\n> +\n> +NAME\n> +----\n> +git-show-refs - Lists refs in various formats\n[...]\n> +EXAMPLES\n> +--------\n> +\n> +Show most recent 16 tags for consumption by gitweb::\n> + git-show-refs --count=16 --sort=-taggerdate,name \\\n> + --format='%(taggerdate) %(name)\\t%(tag)\\t%(subject)' 'tags/*'\n> +\n> +`git-branch` without argument::\n> + git-show-refs --format='%(ishead)%(name)' 'heads/*'\n> +\n> +`git-tag -l`::\n> + git-show-refs tags/*\n\n`git-ls-remotes .` is suspiciously missing from the examples.\n\nFormat needs to somewhat incorporate line for referencing object for that, \nif it exists.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"24972","messageId":"eb9mlg$68v$1@sea.gmane.org","threadId":"5163","inReplyTo":"eb8cdh$s6n$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-08T09:48:41Z","receivedAt":"2006-08-08T09:48:41Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> With two scripts attached to the first post in this thread it would be\n> simple to apply pre-rename patch, by converting gitweb to pre-rename using\n> gitweb-unrename.sh script, then applying patch, then restoring new names\n> using gitweb-rename.sh script, and finally comitting changes (or amending\n> commit).\n\nOr just apply corrected gitweb-rename.sh script (see below) to patch (mbox),\nand then apply and commit the \"after rename\" patch.\n\n#!/bin/sh\n\nif test -z \"$1\"; then\n FILE=`git rev-parse --show-cdup`gitweb/gitweb.perl\nelse\n FILE=$1\nfi\n\necho \"Great subroutine renaming: $FILE\"\nperl -s -p -i.re~ \\\n -e 's/\\bgit_get_referencing\\b/format_mark_referencing/;' \\\n -e 's/\\bgit_read_head\\b/git_get_head/;' \\\n -e 's/\\bread_info_ref\\b/git_read_info_refs/;' \\\n -e 's/\\bdate_str\\b/parse_date/;' \\\n -e 's/\\bgit_read_tag\\b/parse_tag/;' \\\n -e 's/\\bgit_read_commit\\b/parse_commit/;' \\\n -e 's/\\bgit_blob_plain_mimetype\\b/blob_plain_mimetype/;' \\\n -e 's/\\bgit_page_nav\\b/git_print_page_nav/;' \\\n -e 's/\\bgit_header_div\\b/git_print_header_div/;' \\\n \"$FILE\"\n\n# end of gitweb-rename.sh\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"24973","messageId":"eb9mpt$68v$2@sea.gmane.org","threadId":"5163","inReplyTo":"7vejvsyum8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-08T09:51:03Z","receivedAt":"2006-08-08T09:51:03Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n\n> +`git-branch` without argument::\n> + git-show-refs --format='%(ishead)%(name)' 'heads/*'\n\n git-show-refs --format='%(ishead?\"* \":\" \")%(name)' 'refs/heads/*'\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"24987","messageId":"ebak5n$etr$1@sea.gmane.org","threadId":"5163","inReplyTo":"7vejvsyum8.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-show-refs (was: [PATCH/RFC] gitweb: Great subroutines renaming)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-08T18:12:18Z","receivedAt":"2006-08-08T18:12:18Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> +::\n> +       A string that interpolates `%(field name)` from the\n> +       object pointed at by a ref being shown.  When\n> +       unspecified, `%(name)` is used.\n\nWouldn't it be better to (re)use notation of rpm's --query-format, \ni.e. use %{name}, or %30{name}, or %-30{name} for single scalar values,\nuse :typetag output formats, like ':date' (Use strftime(3) \"%c\" format.) and\n':day' (Use strftime(3) \"%a %b %d %Y\" format.) for epoch/timestamp field,\nuse square brackets for iterating over multivalue output, e.g.\n\"[parent: %{parent}]\" for writing out all parents, etc.\n\nPerhaps we could even borrow some code...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"24994","messageId":"7voduvugl9.fsf@assigned-by-dhcp.cox.net","threadId":"5163","inReplyTo":"eb9m30$3ef$2@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-08T20:18:10Z","receivedAt":"2006-08-08T20:18:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> `git-ls-remotes .` is suspiciously missing from the examples.\n\nBecause the point of show-refs was not to replace it only for\nthe local case.\n\n> Format needs to somewhat incorporate line for referencing object for that, \n> if it exists.\n\nAlso I do not think you would want \"ref^{}\" style dereferencing\nls-remotes does for gitweb anyway.\n\nWhat gitweb might want is \"what type of object is this tag\npointing at\" and \"what is the object pointed at by this tag\"\n(both used on \"Tags\" list). I think show-refs specification\nallows you to do that inexpensively.\n\n> Wouldn't it be better to (re)use notation of rpm's --query-format, \n> i.e. use %{name}, or %30{name}, or %-30{name} for single scalar values,\n> use :typetag output formats,...\n\nI did not do them because these enhancements are not needed to\nunblock you from optimizing git_get_* calls in gitweb. These\nenhancement can come later as long as the initial syntax is\nsimple, clean and extensible enough, which I think it is.\n"},{"id":"24995","messageId":"ebaru7$951$1@sea.gmane.org","threadId":"5163","inReplyTo":"7voduvugl9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-08T20:24:52Z","receivedAt":"2006-08-08T20:24:52Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n\n>> Wouldn't it be better to (re)use notation of rpm's --query-format, \n>> i.e. use %{name}, or %30{name}, or %-30{name} for single scalar values,\n>> use :typetag output formats,...\n> \n> I did not do them because these enhancements are not needed to\n> unblock you from optimizing git_get_* calls in gitweb. These\n> enhancement can come later as long as the initial syntax is\n> simple, clean and extensible enough, which I think it is.\n\nYes, that's true. I'm wondering if %(fieldname) of %{fieldname} would be\nbetter.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"24998","messageId":"ebauq1$kcb$1@sea.gmane.org","threadId":"5163","inReplyTo":"200608071626.52655.jnareb@gmail.com","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-08T21:13:51Z","receivedAt":"2006-08-08T21:13:51Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> Renames:\n> - git_get_referencing => format_mark_referencing\n> - git_read_head => git_get_head\n> - read_info_ref => git_read_info_refs\n> - date_str => parse_date\n> - git_read_tag => parse_tag\n> - git_read_commit => parse_commit\n> - git_blob_plain_mimetype => blob_plain_mimetype\n> - git_page_nav => git_print_page_nav\n> - git_header_div => git_print_header_div\n\nSummary of discussion: using *_read_* to distinguish between git calling\ncommands, and file reading commands is not a good idea. So now the\nguideline is to be more fluid with *_get_* vs *_read_* subroutine naming:\nit would depend on the noun after _get_ or _read_.\n\n\nProposed renames:\n1. Renames I think everybody would agree on\n - git_get_referencing => format_mark_referencing\n\n - date_str => parse_date\n - git_read_tag => parse_tag\n - git_read_commit => parse_commit\n\n - git_blob_plain_mimetype => blob_plain_mimetype\n\n - git_page_nav => git_print_page_nav\n - git_header_div => git_print_header_div\n\n\n2. Renames about which I'm less sure\n - git_read_head => git_get_head_hash\n - git_read_hash => git_get_hash_by_ref\n\n - git_read_description => git_project_description\n - git_read_projects => git_get_projects_list or git_list_projects\n\n - read_info_ref => git_read_info_refs => git_get_references\n (this one depend too much on implementation, which might be changed to \n parsing 'git ls-remotes .' output instead of relying on info/refs being\n up to date thanks to git-update-server-info in post-update hook, \n and on its format).\n\n - age_string => ????\n (it returns 'nn ago' string)\n\n\nThoughts? Comments? I'm especially interested in answer of other people\nworking on gitweb (Luben Tuikov, Matthias Lederhofer, Jeff King, \nSham Chukoury, and others).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25000","messageId":"7vu04mucaq.fsf@assigned-by-dhcp.cox.net","threadId":"5163","inReplyTo":"ebauq1$kcb$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-08T21:50:53Z","receivedAt":"2006-08-08T21:50:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Summary of discussion: using *_read_* to distinguish between git calling\n> commands, and file reading commands is not a good idea. So now the\n> guideline is to be more fluid with *_get_* vs *_read_* subroutine naming:\n> it would depend on the noun after _get_ or _read_.\n\nI suspect it is summary of discussion between you and yourself ;-).\n\nI still do not think get_* vs read_* mean anything. You get\ninformation somehow, and maybe reading from a pre-existing file\nmight be one way to do so, or reading from a pipe to a command\nmight be another way to do so, but it does not change an iota\nthat you are retrieving information.\n\n> Proposed renames:\n> 1. Renames I think everybody would agree on\n> - git_get_referencing => format_mark_referencing\n>\n> - date_str => parse_date\n> - git_read_tag => parse_tag\n> - git_read_commit => parse_commit\n>\n> - git_blob_plain_mimetype => blob_plain_mimetype\n\nDoes it matter that the function is used in blob-plain? In\nother words, how would this function, blob-plain-mimetype, be\ndifferent if we were to have another function called blob-mimetype?\n\nHow about calling it \"guess-mimetype\"?\n\n> - git_page_nav => git_print_page_nav\n> - git_header_div => git_print_header_div\n\nBoth sounds sane (I would have said \"git-show-blah\" if I were\ndoing this myself, though).\n\n> - git_read_head => git_get_head_hash\n> - git_read_hash => git_get_hash_by_ref\n\nBoth sounds sane.\n\n> - git_read_description => git_project_description\n\nNo verbs in the renamed one feels awkward.\ngit-get-project-description, perhaps.\n\n> - git_read_projects => git_get_projects_list or git_list_projects\n\nlist-projects is probably the most natural name for something\nthat gives a list to the end user. If you are getting the list\nin-core for further processing, the name is misleading.\n\nPerhaps git-get-projects-list is more appropriate.\n\n> - read_info_ref => git_read_info_refs => git_get_references\n> (this one depend too much on implementation, which might be changed to \n> parsing 'git ls-remotes .' output instead of relying on info/refs being\n> up to date thanks to git-update-server-info in post-update hook, \n> and on its format).\n\nI am not worried too much about the format (because clone/fetch\nover http depends on it), but reading from ls-remote self would\nmake it unnecessary to run update-server-info if a repo is not\nserved over http but is shown over gitweb.\n\n> - age_string => ????\n\nGood name as is, but if you want consistent, it formats the\ntimestamp into age, so it would fall into format-blah family.\n"},{"id":"25002","messageId":"ebb3fm$2md$1@sea.gmane.org","threadId":"5163","inReplyTo":"7vu04mucaq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-08T22:33:40Z","receivedAt":"2006-08-08T22:33:40Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n\n>> - git_blob_plain_mimetype => blob_plain_mimetype\n> \n> Does it matter that the function is used in blob-plain? In\n> other words, how would this function, blob-plain-mimetype, be\n> different if we were to have another function called blob-mimetype?\n> \n> How about calling it \"guess-mimetype\"?\n\nThere are two functions, mimetype_guess_file and mimetype_guess, of which\nfirst one gets mimetype of file based on specified mime.types like file,\nsecond tries $mimetypes_file then '/etc/mime.types', while currently named\ngit_blob_plain_mimetype subroutine first tries mimetype_guess, then checks\nif the file is text file (-T $fd) and if not uses some built in mime.types\nrules. Perhaps current mimetype_guess could be embedded into current\ngit_blob_plain_mimetype.\n\nAll those subroutines need better names I think.\n \n>> - git_page_nav => git_print_page_nav\n>> - git_header_div => git_print_header_div\n> \n> Both sounds sane (I would have said \"git-show-blah\" if I were\n> doing this myself, though).\n\nThey are called among print statements. I'm not sure if some of them\nwouldn't be better converted to format_* types subroutines.\n \n>> - read_info_ref => git_read_info_refs => git_get_references\n>> (this one depend too much on implementation, which might be changed to \n>> parsing 'git ls-remotes .' output instead of relying on info/refs being\n>> up to date thanks to git-update-server-info in post-update hook, \n>> and on its format).\n> \n> I am not worried too much about the format (because clone/fetch\n> over http depends on it), but reading from ls-remote self would\n> make it unnecessary to run update-server-info if a repo is not\n> served over http but is shown over gitweb.\n\nDo the git_get_references for this subroutine, which returns hashref which\nkeys are ids, and values are refs pointing to the key id, sounds good?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25016","messageId":"ebcd8r$bi7$1@sea.gmane.org","threadId":"5163","inReplyTo":"7vejvsyum8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-09T10:26:50Z","receivedAt":"2006-08-09T10:26:50Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n>> Matthias Lederhofer has noticed that parsing all the tags in \"summary\" and\n>> \"tags\" views, while we use only epoch/timestamp information to sort them\n>> and discard most of parsed input, is bottleneck due to the fact that\n>> usually number of tags is linear with history (version tags) and the fact\n>> that for each tag is one invocation of git (one fork, two execs).\n> \n> Maybe we would want to expose for_each_ref somehow to the\n> command level then. Looking at how \"git branch\" without any\n> argument lists the branches, and how \"git tag -l\" lists the\n> tags, it appears that we could benefit from such a command [*1*].\n\n> -- >8 -- [*1*] -- >8 --\n> [PATCH] git-show-refs\n> \n> Implementation is left as an exercise ;-)\n[...]\n> +SYNOPSIS\n> +--------\n> +'git-show-refs' [--count=] [--sort=] [--format=] []\n\nIt would be useful for application in gitweb to have [-l|--count-lines]\noption which would print number of lines (excluding the one with number\nof lines) before any output. It could be used to know before reading all\nthe output how many lines would be, and if there is something more than\n(for --count=) lines. \n\nIt is needed in gitweb to create pagination/paging navigation bar. \nCurrently it is done by reading all the output into array, and \nchecking length of this array.\n\nWhile at it, --skip= would also be nice, although not that\nnecessary.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25018","messageId":"7vy7ty41xb.fsf@assigned-by-dhcp.cox.net","threadId":"5163","inReplyTo":"ebcd8r$bi7$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-09T10:51:44Z","receivedAt":"2006-08-09T10:51:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> It is needed in gitweb to create pagination/paging navigation bar. \n> Currently it is done by reading all the output into array, and \n> checking length of this array.\n\nIf you want to show 10 and do ... when you have more than that,\nthe standard technique is to ask for 11 ;-).\n"},{"id":"25020","messageId":"ebcf9s$h32$1@sea.gmane.org","threadId":"5163","inReplyTo":"7vy7ty41xb.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-09T11:01:32Z","receivedAt":"2006-08-09T11:01:32Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n>> It is needed in gitweb to create pagination/paging navigation bar. \n>> Currently it is done by reading all the output into array, and \n>> checking length of this array.\n> \n> If you want to show 10 and do ... when you have more than that,\n> the standard technique is to ask for 11 ;-).\n\nIt's not a problem to do '...'/'next' link _after_ the body, but\nthe paging navigation bar is at the _top_ of page, before \noutputting the body. See e.g.\n http://www.kernel.org/git/?p=git/git.git;a=shortlog\nthere is \"HEAD * prev * next\" at the top, and \"next\" at the bottom\nof the revision list.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25022","messageId":"7vpsfa4115.fsf@assigned-by-dhcp.cox.net","threadId":"5163","inReplyTo":"ebcf9s$h32$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-09T11:11:02Z","receivedAt":"2006-08-09T11:11:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> It's not a problem to do '...'/'next' link _after_ the body, but\n> the paging navigation bar is at the _top_ of page, before \n> outputting the body.\n\nA good web engineering practice is to prepare the data before\nyou generate a single line of output, so after or top should not\nmake a difference, I would think.\n"},{"id":"25052","messageId":"ebdi1v$cv5$1@sea.gmane.org","threadId":"5163","inReplyTo":"ebb3fm$2md$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-09T20:54:42Z","receivedAt":"2006-08-09T20:54:42Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Subroutines in gitweb: => .\nIf nobody would give any better suggestions, or warn about patches to gitweb\nto be sent, could we do that \"Great subroutines renaming\" some time soon?\nTIA.\n\n* validate_input\n* esc_param\n* esc_html\n* unquote\n* untabify\n* chop_str\n\n* age_class\n* age_string\n* mode_str\n* file_type\n\n* format_log_line_html\n* git_get_referencing => format_mark_referencing (???)\n\n* git_read_head => git_get_head_hash\n* git_read_hash => git_get_hash_by_ref\n* git_get_hash_by_path\n* git_get_type\n* git_get_project_config\n* git_get_project_config_bool\n* git_read_description => git_get_project_description\n* git_read_projects => git_get_projects_list\n* read_info_ref => git_get_references\n* git_read_refs => git_get_refs_list\n\n* date_str => parse_date\n* git_read_tag => parse_tag\n* git_read_commit => parse_commit\n\n* get_file_owner\n* mimetype_guess_file => ??? (reads, parses and uses mime.types like file)\n* mimetype_guess => (to be incorporated in blob_mimetype)\n* git_blob_plain_mimetype => blob_mimetype\n* git_get_paging_nav => ???\n* git_page_nav => git_print_page_nav\n* git_header_div => git_print_header_div\n* git_print_page_path\n* git_diff_print => (to be made obsolete)\n\n* git_header_html\n* git_footer_html\n* die_error\n\n* git_shortlog_body\n* git_tags_body\n* git_heads_body\n\n* git_project_list\n* git_summary\n* git_tag\n* git_blame2 => git_blame (?)\n* git_blame => git_annotate (?)\n* git_tags\n* git_heads\n* git_blob_plain\n* git_blob\n* git_tree\n* git_log\n* git_commit\n* git_blobdiff\n* git_blobdiff_plain\n* git_commitdiff\n* git_commitdiff_plain\n* git_history\n* git_search\n* git_shortlog\n* git_rss\n* git_opml\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25054","messageId":"7v3bc5397r.fsf@assigned-by-dhcp.cox.net","threadId":"5163","inReplyTo":"ebdi1v$cv5$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-09T21:11:52Z","receivedAt":"2006-08-09T21:11:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Subroutines in gitweb: => .\n\nIf it is not too much trouble, having a few line summary of what\neach of the sub does would greatly help judging if the names are\nappropriate.\n"},{"id":"25068","messageId":"ebeorr$amq$1@sea.gmane.org","threadId":"5163","inReplyTo":"7v3bc5397r.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-10T07:57:04Z","receivedAt":"2006-08-10T07:57:04Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n>> Subroutines in gitweb: => .\n> \n> If it is not too much trouble, having a few line summary of what\n> each of the sub does would greatly help judging if the names are\n> appropriate.\n\nSubroutines name guideline, revised:\n* git_ prefix for subroutines related to git commands,\n or to gitweb actions\n* git_get_ prefix for inner subroutines calling git command\n and returning some output\n* parse_ prefix for subroutines parsing some text, or reading and\n parsing some text into hash or list\n* format_ prefix for subroutines formatting/post-processing some\n HTML/text fragment\n* _get_ infix for subroutines which return result\n* _print_ infix for subroutines which print fragment of output\n* _body suffix for subroutines which outputs main part (body)\n of related action\n* _nav suffix for subroutines related to navigation bars\n* _div suffix for subroutines returning or printing div element\n\nCurrent gitweb subroutines, with proposed renames, and short summary.\n\n* validate_input => is_valid_ref, is_valid_path (?)\n universal (too universal) parameter validation\n* esc_param\n quote unsafe chars in link parameters\n* esc_html\n escape to HTML, replace invalid uft8 characters\n* unquote\n unquote filenames quoted and escaped by git\n* untabify\n convert tabs (8 spaces wide tabstops) to spaces\n* chop_str\n shorten string, removing characters entities as whole\n\n* age_class\n CSS class for given age value (in seconds)\n* age_string\n convert age in seconds to \"nn units ago\" string\n* mode_str\n convert file mode in octal to symbolic file mode string\n* file_type\n convert file mode in octal to file type string (directory, symlink,\n file, unknown)\n\n* format_log_line_html\n format line of commit message or tag comment, hyperlinking commitids\n (perhaps in the future comittags, e.g. BUG(nn) support)\n* git_get_referencing => format_mark_referencing (???)\n return HTML fragment generating marker of refs pointing to given object\n\n* git_read_head => git_get_head_hash\n get HEAD ref of given project as hash\n* git_read_hash => git_get_hash_by_ref\n get hash of given ref (e.g. refs/heads/next)\n* git_get_hash_by_path\n get hash of given path at given ref\n* git_get_type\n get type of given object (by hash)\n* git_get_project_config\n return value of given variable in gitweb section\n* git_get_project_config_bool\n return value of given variable in gitweb section, as boolean\n* git_read_description => git_get_project_description\n* git_read_projects => git_get_projects_list\n return list of projects (path, owner)\n* read_info_ref => git_get_references\n return hashref of refs pointing to object given by hash key\n* git_read_refs => git_get_refs_list\n list of hashrefs of parsed ref info\n (parsing to be separated into parse_ref subroutine)\n\n* date_str => parse_date\n given epoch and (optionally) timezone return parsed date as hash\n* git_read_tag => parse_tag\n given tag_id, return parsed tag as Perl hash\n* git_read_commit => parse_commit\n given commit_id (and optionally commit_text to reuse), return parsed\ncommit\n\n* get_file_owner\n return owner of given file, according to user id and gcos field\n* mimetype_guess_file => ??? \n reads and parses mime.types like file, return mimetype of given filename\n* mimetype_guess => (to be incorporated in blob_mimetype)\n try $mimetypes_file, or /etc/mime.types\n* git_blob_plain_mimetype => blob_mimetype\n return mimetype of given (by file descriptor and filename) blob\n* git_get_paging_nav => ???\n return HTML fragment generating \"HEAD * prev * next\" page navigation\n* git_page_nav => git_print_page_nav\n print \"action\" navigation bar, optionally with pager or formats below\n* git_header_div => git_print_header_div\n prints div element of class \"header\" just below navigation bar\n* git_print_page_path\n print div element of class \"page_path\" with current path\n* git_diff_print => (to be made obsolete)\n print diff between two files, using /usr/bin/diff and temporary files\n\n* git_header_html\n prints HTML header of gitweb output \n* git_footer_html\n prints HTML footer of gitweb output\n* die_error\n prints gitweb error page\n\nSubroutines printing table with shortlog, tags, heads respectively\n* git_shortlog_body\n* git_tags_body\n* git_heads_body\n\nAction subroutines\n* git_project_list\n* git_summary\n* git_tag\n* git_blame2 => git_blame (?)\n* git_blame => git_annotate (?)\n* git_tags\n* git_heads\n* git_blob_plain\n* git_blob\n* git_tree\n* git_log\n* git_commit\n* git_blobdiff\n* git_blobdiff_plain\n* git_commitdiff\n* git_commitdiff_plain\n* git_history\n* git_search\n* git_shortlog\n* git_rss\n* git_opml\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25171","messageId":"ebln1v$s6j$1@sea.gmane.org","threadId":"5163","inReplyTo":"200608071626.52655.jnareb@gmail.com","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-12T23:09:24Z","receivedAt":"2006-08-12T23:09:24Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I have series of gitweb patches to send: should I make them pre-rename, or\npost-rename?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25174","messageId":"7v7j1dnzo5.fsf@assigned-by-dhcp.cox.net","threadId":"5163","inReplyTo":"ebln1v$s6j$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-13T02:21:30Z","receivedAt":"2006-08-13T02:21:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> I have series of gitweb patches to send: should I make them pre-rename, or\n> post-rename?\n\nDo people happy with the general naming guidelines (I am)?\n\nI'll be pushing out 1.4.2 this weekend, and then moving all the\ngitweb stuff pending in \"next\" to \"master\" after that.\n\nLet's have the rename immediately on top of it first, then\ncontinue cleaning up after that.\n"},{"id":"25175","messageId":"7vzme9mktk.fsf@assigned-by-dhcp.cox.net","threadId":"5163","inReplyTo":"7v7j1dnzo5.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-13T02:27:35Z","receivedAt":"2006-08-13T02:27:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jakub Narebski writes:\n>\n>> I have series of gitweb patches to send: should I make them pre-rename, or\n>> post-rename?\n>\n> Do people happy with the general naming guidelines (I am)?\n\nAh, the sentence does not parse X-<. Do people find them acceptable?\n"},{"id":"25180","messageId":"ebmrbm$umk$1@sea.gmane.org","threadId":"5163","inReplyTo":"7v7j1dnzo5.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-13T09:29:00Z","receivedAt":"2006-08-13T09:29:00Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n>> I have series of gitweb patches to send: should I make them pre-rename,\nor\n>> post-rename?\n> \n> Do people happy with the general naming guidelines (I am)?\n> \n> I'll be pushing out 1.4.2 this weekend, and then moving all the\n> gitweb stuff pending in \"next\" to \"master\" after that.\n> \n> Let's have the rename immediately on top of it first, then\n> continue cleaning up after that.\n\nSo after 1.4.2 gitweb patches should be based on next, or on master?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25202","messageId":"7vejvki3bh.fsf@assigned-by-dhcp.cox.net","threadId":"5163","inReplyTo":"ebmrbm$umk$1@sea.gmane.org","subject":"Re: [PATCH/RFC] gitweb: Great subroutines renaming","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-14T00:11:30Z","receivedAt":"2006-08-14T00:11:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>> I'll be pushing out 1.4.2 this weekend, and then moving all the\n>> gitweb stuff pending in \"next\" to \"master\" after that.\n>> \n>> Let's have the rename immediately on top of it first, then\n>> continue cleaning up after that.\n>\n> So after 1.4.2 gitweb patches should be based on next, or on master?\n\nWell, since \"git diff master next -- gitweb/\" reports empty, the\nquestion should not matter at this moment ;-).\n\nHere are my preferences, as a general guideline:\n\n * If it is a general clean-up (e.g. changing a function\n signature declared in cache.h to tighten constness), I would\n prefer two patches; one to apply on \"master\", and another one\n created by assuming:\n\n - your first patch for \"master\" is accepted;\n - resulting \"master\" (with your first patch applied) will be\n merged into \"next\";\n\n Then the other patch is to clean-up the remaining stuff\n introduced between \"master\" and \"next\" (e.g. the function\n whose signature you changed in the first patch may have more\n call sites in \"next\" you may need to fix them up).\n\n If you know the specific topic I internally have (you can\n tell them by looking at the merge commits on \"next\"),\n separating the remainder patch into one per topic would be\n even nicer, but that is probably too much work to ask from\n contributors.\n\n Most of the time I can do this split myself, though, so it is\n Ok to send a patch to fix things up only in \"master\", and\n have me find out that it breaks \"next\", at that time I may\n fix things up myself similarly or I may ask you to send in a\n separete patch in similar spirit to fix up things in \"next\".\n\n * If it is a new series, I would prefer things be based on\n \"master\", unless you use some feature (either internal or\n external) that only exists in \"next\" or in \"pu\".\n\n * If it is a follow-up on stuff still in \"next\", obviously\n basing the patch on \"master\" is not possible.\n\n * If you have independent fix even though we have stuff that\n touch the same general area in \"next\", it is very much\n preferable if it applies to \"master\". A critical fix for\n \"next\" that does not apply to \"master\" is taking the fix\n hostage to whatever is in \"next\".\n\n * If you need to base on \"next\", telling me why (i.e. \"this\n uses such and such function which are not in master\") helps\n me identify which topic I internally have to base a topic to\n house your series in.\n\n * If you need to base on \"pu\", think twice. You will be taken\n hostage by whatever you are basing on (this is the same if\n you base on something in \"next\", but \"pu\" is for stuff of\n even more dubious merits than \"next\"). On the other hand,\n your new series may turn out to be the killer application for\n the feature that was earlier felt not-so-useful and help it\n (and your series) merged to \"next\".\n"}]}