Jakub Narebski <jnareb@xxxxxxxxx> writes: > 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_. I suspect it is summary of discussion between you and yourself ;-). I still do not think get_* vs read_* mean anything. You get information somehow, and maybe reading from a pre-existing file might be one way to do so, or reading from a pipe to a command might be another way to do so, but it does not change an iota that you are retrieving information. > 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 Does it matter that the function is used in blob-plain? In other words, how would this function, blob-plain-mimetype, be different if we were to have another function called blob-mimetype? How about calling it "guess-mimetype"? > - git_page_nav => git_print_page_nav > - git_header_div => git_print_header_div Both sounds sane (I would have said "git-show-blah" if I were doing this myself, though). > - git_read_head => git_get_head_hash > - git_read_hash => git_get_hash_by_ref Both sounds sane. > - git_read_description => git_project_description No verbs in the renamed one feels awkward. git-get-project-description, perhaps. > - git_read_projects => git_get_projects_list or git_list_projects list-projects is probably the most natural name for something that gives a list to the end user. If you are getting the list in-core for further processing, the name is misleading. Perhaps git-get-projects-list is more appropriate. > - 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). I am not worried too much about the format (because clone/fetch over http depends on it), but reading from ls-remote self would make it unnecessary to run update-server-info if a repo is not served over http but is shown over gitweb. > - age_string => ???? Good name as is, but if you want consistent, it formats the timestamp into age, so it would fall into format-blah family. - : 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