2011/11/16 Jonathan Nieder <jrnieder@xxxxxxxxx>: > Ramkumar Ramachandra wrote: >> Junio C Hamano wrote: > >>> Or perhaps http://thread.gmane.org/gmane.comp.version-control.git/184963/focus=185436 >> >> I noticed that sha1_to_hex() also operates like this. The >> resolve_ref() function is really important, but using the same >> technique for these tiny functions is probably an overkill > > I don't follow. Do you mean that not being confusing is overkill, > because the function is small that no one will bother to look up the > right semantics? Wait, that sentence didn't come out the way I > wanted. ;-) > > Jokes aside, here's a rough series to do the git_path -> > git_path_unsafe renaming. While writing it, I noticed a couple of > bugs, hence the two patches before the last one. Patch 2 is the more > interesting one. Or perhaps - kill git_path(const char *fmt, ...) in favor of git_pathdup() companion - git_path(const char *path) maintains a small hash table to keep track of all returned strings based with "path" as key. Out of 142 git_path() calls in my tree, 97 of them are in form git_path("some static string"). git_path() could learn to keep track of all generated strings while keep it convenient to use. I suspect with some macro magic, we can keep track of generated strings without a hash table. -- Duy -- To unsubscribe from this list: 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