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

From: Junio C Hamano <gitster@pobox.com>
To: Karsten Blees <karsten.blees@gmail.com>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>,
	Tanay Abhra <tanayabh@gmail.com>,
	git@vger.kernel.org, Ramkumar Ramachandra <artagnon@gmail.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [PATCH v3 2/3] config: add hashtable for config parsing & retrieval
Date: Wed, 25 Jun 2014 13:53:58 -0700	[thread overview]
Message-ID: <xmqqk38490d5.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <53AB2FAA.0@gmail.com> (Karsten Blees's message of "Wed, 25 Jun 2014 22:23:06 +0200")

Karsten Blees <karsten.blees@gmail.com> writes:

> Am 25.06.2014 20:13, schrieb Junio C Hamano:
>> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>>> I had expected to see one hash table per file/blob, with the three
>>> standard config hash tables linked together to implement the scope/
>>> priority rules. (Well, these could be merged into one, as the current
>>> code does, since that makes handling "multi" keys slightly easier).
>> 
>> Again, good point....
>
> Is this additional complexity really necessary?

Nothing is *really* necessary ;-) and it is possible that the best
balance may be at "parse a single chain of files into a single
hashtable for a config-set, and if anything changes, re-read
everything from scratch".

The point Ramsay raised about being able to share the pre-parsed
$HOME/.gitconfig across multiple config-sets (one for the top-level
superproject, and the others for submodules, when having to work
across module boundaries) triggered this thought experiment (aka "I
am not married to the approach") to use one table per source.  If we
wanted to take advantage of updating a single file and not having to
re-read the whole thing, includes need to be handled a bit more
carefully than "one config-file for one source", as you noticed, and
a single source may have to be split into multiple pieces.

And it is possible that the complexity necessary to do these
correctly may make it not worth pursuing the approach.  Or it may
not.  I don't know at this point, and thinking these things through
to arrive at a good design is part of the GSoC project after all, so
I'd rather not to think it through to the end myself ;-).

> What's the use case for this? Do you expect e.g. 'git gc' to
> detect changed depth/window size at run time and adjust the
> algorithm accordingly?

I did write "detect" but I think a more realistic example is that we
do git-config-set internally and wish to see the effect inside the
same process (i.e. something like "pull --set-upstream" that sets
configuration variable for later invocations and also perform the
operation with the configuration in effect at the same time).