Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> When the submodule script that uses "git config -f .gitmodules" is
>> converted into C, if the updated config API is ready, it may be able
>> to do something like these in a single program:
>>
>> const char *url;
>> struct config_set *gm_config;
>>
>> /* read from $GIT_DIR/config */
>> url = git_config_get_string("remote.origin.url");
>>
>> /*
>> * allow us to read from .gitmodules; the parameters are
>> * list of files that make up the configset, perhaps.
>> */
>> gm_config = git_configset_new(".gitmodules", NULL);
>>
>>
>> if (!git_configset_get_bool(gm_config, "submodule.frotz.ignore")) {
>> /* do a lot of stuff for the submodule */
>> ...
>> }
>>
>> /* when we are done with the configset */
>> git_configset_clear(gm_config);
>
> Isn't that a bit overkill? Why not just let the caller manage a hashmap
> directly instead of a config_set?
Because I had an experience under my belt of a painful refactoring
of "the_index" which turned out to be not just a single array, I
simply suspect that the final data structure to represent a "set of
config-like things" will not be just a single hashmap, hence I do
prefer to have one layer of abstraction "struct config_set", which
would contain a hashmap and possibly more. Doesn't "is the hashmap
initialized" bit belong there, for example?
--
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