git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 2/3] config: add hashtable for config parsing & retrieval

From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date
Jun 26, 2014, 16:15 UTC
Message-ID
<vpq8uojoddu.fsf@anie.imag.fr>
In-Reply-To
<53A99A28.1090302@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Hmm, maybe. The "... take advantage of the new code" refers to the
> possibility (or otherwise) of re-using your work to update these
> "older API" functions to the new API style. (also, see Junio's response).

I agree that, while caching the usual config files is the most important, allowing other users of the config code to use non-callback functions would be nice too.

Not really for efficiency, but because I find it far more natural to ask "what's the value of config key XYZ" to the code than to ask "can you parse all config keys in the file, let me know, and I'll tell you later which ones I'm interested in".

> [In order to do this, I would have expected to see one hash table
> for each file/blob, so the singleton object took me by surprise.]

The singleton could be fine as long as it is optional. We can have an API looking like:

int git_config_get_string(const char *key, const char **value) {
	return git_config_get_string_from(the singleton config cache,
                                          key, value);
}
int git_config_get_string_from(struct hashmap *map, const char *key, const char **value);

(or take a structure representing "a set of config files" instead of directly the hashmap)

Now, the good news is that such API can be written later, without breaking the API. So I'd say it's fine to keep the code as-is for now, and make it more general later. No strong opinion, though.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Previous: Ramsay JonesNext: Junio C Hamano
Message 12 of 35 in “git config cache & special querying api utilizing the cache”
  1. 0/3 git config cache & special querying api utilizing the cacheTanay Abhra, Jun 23, 2014
  2. 1/3 string-list: add string_list initialiser helper functionsTanay Abhra, Jun 23, 2014
  3. Torsten BögershausenJun 23, 2014
  4. Tanay AbhraJun 23, 2014
  5. 2/3 config: add hashtable for config parsing & retrievalTanay Abhra, Jun 23, 2014
  6. Matthieu MoyJun 23, 2014
  7. Tanay AbhraJun 24, 2014
  8. Karsten BleesJun 25, 2014
  9. Ramsay JonesJun 23, 2014
  10. Tanay AbhraJun 23, 2014
  11. Ramsay JonesJun 24, 2014
  12. Matthieu MoyJun 26, 2014
  13. Junio C HamanoJun 23, 2014
  14. Tanay AbhraJun 24, 2014
  15. Junio C HamanoJun 25, 2014
  16. Tanay AbhraJun 24, 2014
  17. Ramsay JonesJun 24, 2014
  18. Junio C HamanoJun 25, 2014
  19. Karsten BleesJun 25, 2014
  20. Junio C HamanoJun 25, 2014
  21. Matthieu MoyJun 26, 2014
  22. Junio C HamanoJun 26, 2014
  23. Karsten BleesJun 26, 2014
  24. Junio C HamanoJun 26, 2014
  25. Karsten BleesJun 27, 2014
  26. Matthieu MoyJun 27, 2014
  27. Junio C HamanoJun 27, 2014
  28. Junio C HamanoJun 23, 2014
  29. Tanay AbhraJun 24, 2014
  30. Matthieu MoyJun 26, 2014
  31. Karsten BleesJun 25, 2014
  32. Matthieu MoyJun 26, 2014
  33. 3/3 test-config: add usage examples for non-callback query functionsTanay Abhra, Jun 23, 2014
  34. Eric SunshineJun 25, 2014
  35. Tanay AbhraJun 26, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.