On Fri, Mar 14, 2014 at 10:01 AM, Jeff King <p...@peff.net> wrote: > On Tue, Mar 11, 2014 at 09:49:33PM +0530, karthik nayak wrote: > >> On Tue, Mar 11, 2014 at 8:21 PM, Matthieu Moy >> <matthieu....@grenoble-inp.fr> wrote: >> > karthik nayak <karthik....@gmail.com> writes: >> > >> >> Currently we have multiple invocation of git_config() in an >> >> individual invocation of git() which is not efficient. Also, it is >> >> hard to implement new features, >> > >> > I think efficiency is not a real concern here. Config files are small >> > and easy to parse, so parsing them multiple times isn't really >> > noticeable from the performance point of view. >> > >> > OTOH, the extensibility is a real concern, and that should be the main >> > motivation for the project. >> >> Thanks. I understand what you mean. extensibility is the main motivation of >> the >> project, i think that by implementing the cache system we can fix the >> small problems >> (reappearing of headers while setting and unsetting configs) and also >> implement new features >> like to unset a config easily. > > I think the most interesting part of the config idea is turning the > fetching of config variables "inside out". > > That is, right now we turn control over to the config code, which > invokes our callbacks. So we see all variables in sequence, and pick out > the ones that are interesting. We implement precedence with a "last one > wins" technique where we keep overwriting a variable with subsequent > config options. > > This can lead to difficult ordering situations, such as when a config > option _might_ be respected based on another factor (e.g., the presence > of a command line option, as in the status.branch option). > > It also means that it's impossible to tell after the fact whether a > value was set explicitly on the command line, by config, or if we are > using a system default. Most of the time this doesn't matter, but there > are a few cases where we care, and we end up having to manually manage > a separate flag in each case. > > By the phrase "inside out" above, I mean that we could read all config, > and then fetch individual values as we need them. We do need to care > about efficiency here, but only insofar as we don't cause any > regressions (that is, the current system is fine speed-wise, we just > need to make sure that we do not create new problems by calling a slow > lookup in a tight loop or anything like that). > > -Peff
Hello Jeff, Like you said yes, this will be a complete "inside out" change. Thanks for summing it up, really helpful. Currently i am going through the code and understanding how it works currently. Simultaneously working on the proposal[1], would be great to have your feedback on that. Thanks, Karthik [1] https://gist.github.com/KarthikNayak/98569dd34326f7e6813a -- 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
