Matthieu Moy <> writes:

> Junio C Hamano <> 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
More majordomo info at

Reply via email to