Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: >> What is also important is the fast that git_read_* functions are fast, >> with exception of git_read_info_refs... > > Hmph. readdir-refs is quite bad for future compatibility, so is > read_hash. Fast = doesn't call git commands, so no delay for fork+exec. > If you want _fast_ then make the implementation fast (or leave > room to make it fast later); encoding the fastness assumption in > the name IS WRONG. Matthias Lederhofer has noticed that parsing all the tags in "summary" and "tags" views, while we use only epoch/timestamp information to sort them and discard most of parsed input, is bottleneck due to the fact that usually number of tags is linear with history (version tags) and the fact that for each tag is one invocation of git (one fork, two execs). > For example, sub git_get_hash (not git_read_hash) can stay as > (potentially buggy wrt symrefs) "reading from .git/refs/$thing" > or could even be fixed to read from git-rev-parse (which is the > kosher way). If it turns out to be a bottleneck, it could be > rewritten using Git.xs. The same thing for read_refs which I > think should be doing ls-remote on the repository if it wants to > be kosher. True. So _read_ based on actually reading the files is out. git_get_hash_by_ref, git_get_HEAD_hash (or just git_get_ref, git_get_head) return single scalar value; git_read_info_refs and git_read_refs return reference to hash or array, while git_read_projects returns array. So the new guidelines would be: * git_get_ prefix for subroutines related to git repository and returning single scalar (single value). * git_read_ prefix for subroutines related to git repository, reading some files or multiline output, and returning hash reference, or list reference, or list. -- 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