Jakub Narebski wrote: > Renames: > - git_get_referencing => format_mark_referencing > - git_read_head => git_get_head > - read_info_ref => git_read_info_refs > - date_str => parse_date > - git_read_tag => parse_tag > - git_read_commit => parse_commit > - git_blob_plain_mimetype => blob_plain_mimetype > - git_page_nav => git_print_page_nav > - git_header_div => git_print_header_div Summary of discussion: using *_read_* to distinguish between git calling commands, and file reading commands is not a good idea. So now the guideline is to be more fluid with *_get_* vs *_read_* subroutine naming: it would depend on the noun after _get_ or _read_. Proposed renames: 1. Renames I think everybody would agree on - git_get_referencing => format_mark_referencing - date_str => parse_date - git_read_tag => parse_tag - git_read_commit => parse_commit - git_blob_plain_mimetype => blob_plain_mimetype - git_page_nav => git_print_page_nav - git_header_div => git_print_header_div 2. Renames about which I'm less sure - git_read_head => git_get_head_hash - git_read_hash => git_get_hash_by_ref - git_read_description => git_project_description - git_read_projects => git_get_projects_list or git_list_projects - read_info_ref => git_read_info_refs => git_get_references (this one depend too much on implementation, which might be changed to parsing 'git ls-remotes .' output instead of relying on info/refs being up to date thanks to git-update-server-info in post-update hook, and on its format). - age_string => ???? (it returns 'nn ago' string) Thoughts? Comments? I'm especially interested in answer of other people working on gitweb (Luben Tuikov, Matthias Lederhofer, Jeff King, Sham Chukoury, and others). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html