Matthieu Moy writes:
> Junio C Hamano writes:
>
>> After thinking about it a bit more, I think support
>> needs to be done not as a mere client of the generic, uncached
>> git_config() API that we have had for forever, like the current
>> iteration, but needs to know a bit more about the state
Tanay Abhra writes:
> Noted, still I want to add that even when GSoC finishes, I won't leave the
> work unfinished. I had said that I wanted to continue being part of the Git
> community and I mean that. :)
This is a good thing, but you shouldn't rely on it for your GSoC. After
the GSoC finishes
Junio C Hamano writes:
> After thinking about it a bit more, I think support
> needs to be done not as a mere client of the generic, uncached
> git_config() API that we have had for forever, like the current
> iteration, but needs to know a bit more about the state the caller
> of the callback (
Junio C Hamano writes:
>> * Still, making sure that the (file, line) is doable later without too
>> much change is good. So, if indeed, moving all code to another file is
>> required, then it may make sense to do it now to avoid code move
>> later.
>
> Good thinking. As long as the code is
On 7/9/2014 7:49 PM, Matthieu Moy wrote:
> Tanay Abhra writes:
>
>
> My opinion on this:
>
> * It's low priority. I think the order of priority should be (high to
> low)
>
> 1) Finish and get the current series into pu (we're almost there, it's
> not time to back off and restart somet
Matthieu Moy writes:
> My opinion on this:
>
> * It's low priority. I think the order of priority should be (high to
> low)
>
> 1) Finish and get the current series into pu (we're almost there, it's
> not time to back off and restart something new).
>
> 2) Work on the other series that
Tanay Abhra writes:
> Also, I tried implementing Junio's request about saving the line
> number and the file name for each
> key-value pair. I had some success, but with some changes,
My opinion on this:
* It's low priority. I think the order of priority should be (high to
low)
1) Finish a
On 7/9/2014 5:42 PM, Matthieu Moy wrote:
> Tanay Abhra writes:
>
>> diff --git a/Documentation/technical/api-config.txt
>> b/Documentation/technical/api-config.txt
>> index 230b3a0..65a6717 100644
>> --- a/Documentation/technical/api-config.txt
>> +++ b/Documentation/technical/api-config.txt
>
Tanay Abhra writes:
> diff --git a/Documentation/technical/api-config.txt
> b/Documentation/technical/api-config.txt
> index 230b3a0..65a6717 100644
> --- a/Documentation/technical/api-config.txt
> +++ b/Documentation/technical/api-config.txt
> +`int git_config_get_bool(const char *key, int *de
Currently `git_config()` uses a callback mechanism and file rereads for
config values. Due to this approach, it is not uncommon for the config
files to be parsed several times during the run of a git program, with
different callbacks picking out different variables useful to themselves.
Add a `con
10 matches
Mail list logo
