Jeff King <p...@peff.net> writes: > If we had the keys in-memory, we could reverse this: config code asks > for keys it cares about, and we can do an optimized lookup (binary > search, hash, etc).
I'm actually dreaming of a system where a configuration variable could be "declared" in Git's source code, with associated type (list/single value, boolean/string/path/...), default value and documentation (and then Documentation/config.txt could become a generated file). One could imagine a lot of possibilities like $ git config --describe <some-variable> Type: boolean Default value: true Description: ... Somehow, do for config variables what has been done for command-line option parsing. Migrating the whole code to such system would take time, but creating the system and applying it to a few examples might be feasible as a GSoC project. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
