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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 25, 2014, 20:53 UTC
Message-ID: <xmqqk38490d5.fsf@gitster.dls.corp.google.com>
In-Reply-To: <53AB2FAA.0@gmail.com>

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

Show 10 quoted lines

> 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).