Matthieu Moy writes:
>>> I'd just replace "list" with "array" and use
>>> Documentation/technical/api-allocation-growing.txt.
>>>
>>> But I can't think of a better way.
>>
>> Presumably this array will reflect the order the source file told us
>> about the keys and their values; I wonder if the
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Tanay Abhra writes:
>>
>>> On 7/25/2014 2:52 AM, Ramsay Jones wrote:
However, I think it you could create a list of >>> entry, string-list index> pairs in the config_set and use that to do
the iteration. A bit ugly, but it should work
Matthieu Moy writes:
> Tanay Abhra writes:
>
>> On 7/25/2014 2:52 AM, Ramsay Jones wrote:
>>> However, I think it you could create a list of >> entry, string-list index> pairs in the config_set and use that to do
>>> the iteration. A bit ugly, but it should work.
>>
>> Thanks for the advice, tha
Tanay Abhra writes:
> On 7/25/2014 2:52 AM, Ramsay Jones wrote:
>> However, I think it you could create a list of > entry, string-list index> pairs in the config_set and use that to do
>> the iteration. A bit ugly, but it should work.
>
> Thanks for the advice, that is exactly what I am doing.
I
On 7/25/2014 2:52 AM, Ramsay Jones wrote:
> On 24/07/14 20:54, Junio C Hamano wrote:
>> Tanay Abhra writes:
>>
>>> If we take the easy way out, fixing UI mistakes would be easier,
>>> just replace git_config_cache() with git_config_raw() for such cases.
>>
>> I do not think that would fly well.
On 24/07/14 20:54, Junio C Hamano wrote:
> Tanay Abhra writes:
>
>> If we take the easy way out, fixing UI mistakes would be easier,
>> just replace git_config_cache() with git_config_raw() for such cases.
>
> I do not think that would fly well.
>
> The kind of "let's migrate funcname users to
Tanay Abhra writes:
> If we take the easy way out, fixing UI mistakes would be easier,
> just replace git_config_cache() with git_config_raw() for such cases.
I do not think that would fly well.
The kind of "let's migrate funcname users to xfuncname while still
supporting the old uses" change w
On 7/25/2014 12:50 AM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Tanay Abhra writes:
>>
>>> For core the only test failing was xfuncname vs funcname,
>>
>> Being a little pessimistic: there may be other cases where the hashtable
>> magically gives the right order for existing tests, bu
Matthieu Moy writes:
> Tanay Abhra writes:
>
>> For core the only test failing was xfuncname vs funcname,
>
> Being a little pessimistic: there may be other cases where the hashtable
> magically gives the right order for existing tests, but that would fail
> for untested use-cases.
>
> But I can
On Thu, Jul 24, 2014 at 08:47:45PM +0200, Matthieu Moy wrote:
> Tanay Abhra writes:
> > Also can you name any third party apps that use the git_config()
> > system on which I can test the patches.
>
> There are probably tons of. I can think of git-multimail.
CGit [1] is probably the only one tha
Tanay Abhra writes:
> For core the only test failing was xfuncname vs funcname,
Being a little pessimistic: there may be other cases where the hashtable
magically gives the right order for existing tests, but that would fail
for untested use-cases.
But I can't think of any such case.
> so the
>
> I haven't formed a firm opinion whether preserving the order is
> necessary at git_config() iteration level yet. If the only in-core
> user that will be broken by not doing so is xfuncname vs funcname,
> it may not be too bad, but it will constrain us in the future, which
> is a lot bigger p
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> in my ~/.gitconfig and then for a particular project I wanted to use
>> a custom pattern in its .git/config but it was sufficient to define
>> the pattern without using extended regexp, I would be tempted to say
>>
>> diff.foo.funcname "Win
Junio C Hamano writes:
> in my ~/.gitconfig and then for a particular project I wanted to use
> a custom pattern in its .git/config but it was sufficient to define
> the pattern without using extended regexp, I would be tempted to say
>
> diff.foo.funcname "Wine$"
The point is: to do that,
Tanay Abhra writes:
> t4018-diff-funcname.sh fails for the new `git_config()` which uses the
> configuration files caching layer internally.
> The test introduced in commit d64d6cdc checks that whether `xfuncname` takes
> precedence over `funcname` variable which was not guaranteed by config API
On Wed, Jul 23, 2014 at 2:42 PM, Tanay Abhra wrote:
> t4018-diff-funcname.sh fails for the new `git_config()` which uses the
> configuration files caching layer internally.
> The test introduced in commit d64d6cdc checks that whether `xfuncname` takes
s/that//
> precedence over `funcname` variab
Tanay Abhra writes:
> Also `funcname` variable is deprecated and not documented properly.
I'd say "purposely undocumented (see 45d9414fa5, Brandon Casey, Sep 18
2008)".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
17 matches
Mail list logo
