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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 25, 2014, 18:21 UTC
Message-ID: <xmqq1tucalzy.fsf@gitster.dls.corp.google.com>
In-Reply-To: <53A9276D.3020503@gmail.com>

Tanay Abhra <tanayabh@gmail.com> writes:

> What changes should I implement in this series? Should I add new
> user facing API adding to the singleton callers which are already in
> this series.

I think the underlying data structures that represent what the entire set of config data is needs to be refined.

We did this kind of conversion once, back when we made it possible to handle more than one instances of in-core cache. You may want to study the series that implemented the transition to learn ideas from.

 - We used to have a single "struct cache_entry **cache", a single
   pair of "unsigned int cache_nr, cache_alloc", etc. and the first
   patch to introduce the feature was to define "struct index_state"
   that holds all of these "what the entire set of data that
   represent the status of the in-core cache is" variables.

 - We also used to have a set of functions that work on the
   singleton instance of the in-core cache (read_cache(),
   write_cache(), etc.).  We introduced a new set of API functions
   to take an explicit pointer to the "struct index_state" we want
   to work on, and made these old "assume the singleton" functions a
   set of thin wrappers that pass &the_index to the corresponding
   new API functions.