Re: [PATCH v7 1/2] add `config_set` API for caching config-like files

Matthieu Moy [off-list ref] writes:

My opinion on this:

* It's low priority. I think the order of priority should be (high to
  low)

  1) Finish and get the current series into pu (we're almost there, it's
     not time to back off and restart something new).

  2) Work on the other series that uses the new API. We don't need to
     change _all_ the uses, but we do need a few tens of them to
     validate the fact that the new API is nice and convenient to use.

  3) Get new actual features for the user (tidy up config files, give
     error messages based on numbers).

  You probably won't finish everything, so just think: if the GSoC ends
  between 1) and 2), how serious is it? if it ends between 2) and 3),
  how serious? If reverse the order, then the risk of having nothing
  finished and mergeable at the end is high. If it happens, the
  community may or may not take over and finish it ...

* Still, making sure that the (file, line) is doable later without too
  much change is good. So, if indeed, moving all code to another file is
  required, then it may make sense to do it now to avoid code move
  later.

Good thinking.  As long as the code is prepared, it is a good idea
to start small and bite off only we can chew at once, do things
incrementally.

quoted

1. config-hash.c had to be shifted to config.c entirely.

Why? I guess one reason is the use of struct cf (are there others?), but
moving just

config_hash_callback
config_hash_add_value
git_configset_add_file

to config.c should do it. Then, config.c could use config-hash.c.

I am not sure why you guys needed a new file config-hash.c to begin
with, actually.  Besides, "hash" in its name is an implementation
detail (what it gives us is a way to grab values for configuration
variables from a config set) which we would rather not want to see.