Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-25 Thread Matthieu Moy
Tanay Abhra tanay...@gmail.com writes:

 On 7/25/2014 2:52 AM, Ramsay Jones wrote:
 However, I think it you could create a list of pointer to hash-table
 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'd just replace list with array and use
Documentation/technical/api-allocation-growing.txt.

But I can't think of a better way.

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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-25 Thread Junio C Hamano
Matthieu Moy matthieu@grenoble-inp.fr writes:

 Tanay Abhra tanay...@gmail.com writes:

 On 7/25/2014 2:52 AM, Ramsay Jones wrote:
 However, I think it you could create a list of pointer to hash-table
 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'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 filename, lineno
information we already have can be used (or unified) with it?

Is the when the last variable in a section disappears, make the
section header go away, with sensible handling of comments around
it part of this GSoC project?  If so, I suspect that the feature
would also want to know where things appear in the original file, so
this data structure may play a role there, too.
--
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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-25 Thread Matthieu Moy
Junio C Hamano gits...@pobox.com writes:

 Matthieu Moy matthieu@grenoble-inp.fr writes:

 Tanay Abhra tanay...@gmail.com writes:

 On 7/25/2014 2:52 AM, Ramsay Jones wrote:
 However, I think it you could create a list of pointer to hash-table
 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'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 filename, lineno
 information we already have can be used (or unified) with it?

I've thought about this too, and I think it would be really hard.

First, there are several files in the picture (eg. /etc/gitconfig,
~/.gitconfig and .git/config), and even included files hence it's not
even a lexical order (file, line).

Then, even if we had a way to order elements with (file, line),
iterating over the hashtable in this order wouldn't be easy (the naive
way, get the smallest, get the second smallest, ... would be O(n^2)).

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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-25 Thread Junio C Hamano
Matthieu Moy matthieu@grenoble-inp.fr 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 filename, lineno
 information we already have can be used (or unified) with it?

 I've thought about this too, and I think it would be really hard.

Yeah, I do not offhand think of a good solution, either, without
going pointer-crazy and have bidirectional link everywhere X-.
--
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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-24 Thread Matthieu Moy
Junio C Hamano gits...@pobox.com 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, you need to know that funcname exists, hence
read archives of the doc before 2008 (it disapeared in
45d9414fa5599b41578625961b53e18a9b9148c7) or read the code. And if I
read correctly the commit message for the commit, funcname is not
portable so you should use xfuncname anyway.

The real reason for this change is to let the code work with the new
git_config, but I think it's reasonable not to bother with the original
behavior for a feature deprecated so long ago.

That said, I think the commit message should be improved (recall the
drawbacks of funcname).

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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-24 Thread Junio C Hamano
Matthieu Moy matthieu@grenoble-inp.fr writes:

 Junio C Hamano gits...@pobox.com 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, you need to know that funcname exists, hence
 read archives of the doc before 2008 (it disapeared in
 45d9414fa5599b41578625961b53e18a9b9148c7) or read the code. And if I
 read correctly the commit message for the commit, funcname is not
 portable so you should use xfuncname anyway.

 The real reason for this change is to let the code work with the new
 git_config, but I think it's reasonable not to bother with the original
 behavior for a feature deprecated so long ago.

We may be able to explain funcname vs xfuncname away, but the
problem is much deeper, and it is not just you and Tanay, but
anybody who thought that it is a natural and logical conclusion
to emulate git_config() by iterating over in-core hashtable X-

We have assumed that it is OK for git_config() to call its callbacks
with any random order of keys as long as the values for the same key
are given in the same order as the original read from file every
time implementation would have called.  The assumption overlooked
the possibility that values given to two different keys can
semantically interact.  $foo.funcname and $foo.xfuncname being two
different ways to define the same piece of information is merely one
of the many ways such interactions can happen.  For example, by
assuming that orders of callbacks across keys does not matter, we
would be breaking scripts that expected to be able to deal with
something like this:

[character]
name = Snoopy
color = white black

name = Hobbes
color = yellow white black

For *our* own data, we can force them to be spelled this way instead:

[character Snoopy]
color = white black
[character Hobbes]
color = yellow white black

but that misses the point, as our config file format and its
semantics are not only about .git/config but the system is designed
and promoted to be a way for third-party applications to store their
own data as well.

Because we do not condone using libgit.a as a library to link into
third-party applications, git_config() at the C level may not have
to read a random third-party data and call its callback in the
predictable way, but this shows us that git config -l interface
must return the data in the same order as we have done always by
either using the _raw interface to return things uncached, or
teaching by git_config() to also be predicatable.

 That said, I think the commit message should be improved (recall the
 drawbacks of funcname).

In any case, I agree that the log message and the subject is wrong.
It is not that we want to give xfuncname precedence over funcname;
such a behaviour is undesirable if both were in wide use.  It is
papering over the fallout that comes from the loss of ordering
information, which is imposed by the data structure chosen to
represent a config_set.

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 problem.  We will be forbidden from correcting a UI
mistake by using the approach we took to transtion funcname over
to xfuncname (i.e. giving users funcname and allowing the
platform BRE parser that may or may not allow the users to write
backslashed ERE is spreading possible incompatibility among the
participants of a project; explicitly stating that the value is ERE
has fewer compatibility issues), while still supporting funcname
and have them interact in a sane way.
--
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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-24 Thread Tanay Abhra

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

If we give users a choice between two methods git_config_raw() 
git_config_cache(), it would give us a easy fallback if we want
to do something like support xfuncname and funcname for performing
the same function differently.

For core the only test failing was xfuncname vs funcname,
so the situation is not as bad as you think. One course of action
would be leave git_config() as it is, so that third party apps
may not be broken. Provide a function like git_config_cache(),
then rename all the git_config() calls in core to git_config_cache(),
fallback to git_config() where it is not applicable (for example,
git config -l). I haven't thought a lot about it and I haven't
heard Matthieu's opinion about it yet.

Also can you name any third party apps that use the git_config()
system on which I can test the patches. I have seen gitk and gitgui
using the config files to save data.

Cheers,
Tanay Abhra.

  We will be forbidden from correcting a UI
 mistake by using the approach we took to transtion funcname over
 to xfuncname (i.e. giving users funcname and allowing the
 platform BRE parser that may or may not allow the users to write
 backslashed ERE is spreading possible incompatibility among the
 participants of a project; explicitly stating that the value is ERE
 has fewer compatibility issues), while still supporting funcname
 and have them interact in a sane way.
 
--
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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-24 Thread Matthieu Moy
Tanay Abhra tanay...@gmail.com 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 situation is not as bad as you think. One course of action
 would be leave git_config() as it is, so that third party apps
 may not be broken. Provide a function like git_config_cache(),
 then rename all the git_config() calls in core to git_config_cache(),
 fallback to git_config() where it is not applicable (for example,
 git config -l).

I think Junio's point about git config -l is correct: we should just
keep git_config_raw there.

OTOH, renaming git_config to git_config_cache seems a lot of code churn,
so I'd keep the name git_config. Perhaps git_config_raw is no longer a
good name and it could be called git_config_ordered.

If we keep one call to git_config_raw there, then maybe we can use it
for xfuncname/funcname too, and keep the behavior unchanged.

 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.

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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-24 Thread John Keeping
On Thu, Jul 24, 2014 at 08:47:45PM +0200, Matthieu Moy wrote:
 Tanay Abhra tanay...@gmail.com 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 that links with libgit.a and uses the
internal C API.

[1] http://git.zx2c4.com/cgit/
--
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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-24 Thread Junio C Hamano
Matthieu Moy matthieu@grenoble-inp.fr writes:

 Tanay Abhra tanay...@gmail.com 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 situation is not as bad as you think. One course of action
 would be leave git_config() as it is, so that third party apps
 may not be broken. Provide a function like git_config_cache(),
 then rename all the git_config() calls in core to git_config_cache(),
 fallback to git_config() where it is not applicable (for example,
 git config -l).

 I think Junio's point about git config -l is correct: we should just
 keep git_config_raw there.

I have a slight preference of making git_config() do the right thing
and take advantage of caching behaviour, to be honest.  How much
extra effort is necessary in your code to carry a piece of
information, in addition to what lets you say here are the values
associated with that key in the order we read from the files, in
order to be able to say by the way, here is the order of key-value
pairs, if you want to show everything we read in the same order?
If it would be excessive, using _raw() could be an easy way to punt,
but because we know it is easy to decide to punt, I'd like to see us
see if a real solution is feasible first before punting.

 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.

This question does not really matter.

Among the various points, I actually think the last one you omitted
from your quote, closing door to one useful way to fix UI mistakes
in the future, is the most serious one.
--
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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-24 Thread Tanay Abhra


On 7/25/2014 12:50 AM, Junio C Hamano wrote:
 Matthieu Moy matthieu@grenoble-inp.fr writes:
 
 Tanay Abhra tanay...@gmail.com 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 situation is not as bad as you think. One course of action
 would be leave git_config() as it is, so that third party apps
 may not be broken. Provide a function like git_config_cache(),
 then rename all the git_config() calls in core to git_config_cache(),
 fallback to git_config() where it is not applicable (for example,
 git config -l).

 I think Junio's point about git config -l is correct: we should just
 keep git_config_raw there.
 
 I have a slight preference of making git_config() do the right thing
 and take advantage of caching behaviour, to be honest.  How much
 extra effort is necessary in your code to carry a piece of
 information, in addition to what lets you say here are the values
 associated with that key in the order we read from the files, in
 order to be able to say by the way, here is the order of key-value
 pairs, if you want to show everything we read in the same order?
 If it would be excessive, using _raw() could be an easy way to punt,
 but because we know it is easy to decide to punt, I'd like to see us
 see if a real solution is feasible first before punting.


I am thinking over it, lets see if there is a way before we take the
easy route.

 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.
 
 This question does not really matter.
 
 Among the various points, I actually think the last one you omitted
 from your quote, closing door to one useful way to fix UI mistakes
 in the future, is the most serious one.


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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-24 Thread Junio C Hamano
Tanay Abhra tanay...@gmail.com 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 will be done in the callback
functions like userdiff_config().  But it is very typical that
multiple config callback functions are cascaded (e.g. many
eventually end up calling git_default_core_config()); in order to a
workaround you suggest to help a callback in deep in a cascade chain
would require you to see which ones among all the callback functions
will eventually call the callback you are updating for migration and
update all git_config() calls to git_config_raw().

If you fix it properly (assuming it is feasible; I haven't heard if
you even tried to see how much work it would involve), you do not
need to introduce git_config_cached() (or _raw() for that
matter), which is a huge plus.  git_config() would instead do the
right thing automatically, giving the same semantics except that it
does not read the same file twice when it is known that the file has
not changed.

I can understand If we take the easy way out, we do not have to do
much.  But it would not make it any easier---it essentially closes
the door for oops, funcname is error-prone; let's give people
xfuncname type of migration.
--
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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-24 Thread Ramsay Jones
On 24/07/14 20:54, Junio C Hamano wrote:
 Tanay Abhra tanay...@gmail.com 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 will be done in the callback
 functions like userdiff_config().  But it is very typical that
 multiple config callback functions are cascaded (e.g. many
 eventually end up calling git_default_core_config()); in order to a
 workaround you suggest to help a callback in deep in a cascade chain
 would require you to see which ones among all the callback functions
 will eventually call the callback you are updating for migration and
 update all git_config() calls to git_config_raw().
 
 If you fix it properly (assuming it is feasible; I haven't heard if
 you even tried to see how much work it would involve), you do not
 need to introduce git_config_cached() (or _raw() for that
 matter), which is a huge plus.  git_config() would instead do the
 right thing automatically, giving the same semantics except that it
 does not read the same file twice when it is known that the file has
 not changed.
 

I haven't been following this conversation too closely, so if I have
grasped the wrong end of this stick, please accept my apologies! ;-)

Usually if you need to iterate the values in a hash-table in the order
of key insertion, you would simply link the hash-table entries into a
linked list. This assumes that the keys are distinct, or if not, that
you are using a 'multi-map' type of hash-table. Here, if memory serves
me, you are doing the 'multi' bit yourself within the single hash-table
entry for a given key; so its not quite so easy.

However, I think it you could create a list of pointer to hash-table
entry, string-list index pairs in the config_set and use that to do
the iteration. A bit ugly, but it should work.

HTH

ATB,
Ramsay Jones



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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-24 Thread Tanay Abhra


On 7/25/2014 2:52 AM, Ramsay Jones wrote:
 On 24/07/14 20:54, Junio C Hamano wrote:
 Tanay Abhra tanay...@gmail.com 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 will be done in the callback
 functions like userdiff_config().  But it is very typical that
 multiple config callback functions are cascaded (e.g. many
 eventually end up calling git_default_core_config()); in order to a
 workaround you suggest to help a callback in deep in a cascade chain
 would require you to see which ones among all the callback functions
 will eventually call the callback you are updating for migration and
 update all git_config() calls to git_config_raw().

 If you fix it properly (assuming it is feasible; I haven't heard if
 you even tried to see how much work it would involve), you do not
 need to introduce git_config_cached() (or _raw() for that
 matter), which is a huge plus.  git_config() would instead do the
 right thing automatically, giving the same semantics except that it
 does not read the same file twice when it is known that the file has
 not changed.

 
 I haven't been following this conversation too closely, so if I have
 grasped the wrong end of this stick, please accept my apologies! ;-)
 
 Usually if you need to iterate the values in a hash-table in the order
 of key insertion, you would simply link the hash-table entries into a
 linked list. This assumes that the keys are distinct, or if not, that
 you are using a 'multi-map' type of hash-table. Here, if memory serves
 me, you are doing the 'multi' bit yourself within the single hash-table
 entry for a given key; so its not quite so easy.
 
 However, I think it you could create a list of pointer to hash-table
 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.

 HTH
 
 ATB,
 Ramsay Jones
 
 
 
--
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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-23 Thread Matthieu Moy
Tanay Abhra tanay...@gmail.com 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 body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-23 Thread Eric Sunshine
On Wed, Jul 23, 2014 at 2:42 PM, Tanay Abhra tanay...@gmail.com 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` variable which was not guaranteed by config API
 previously and worked only because values were parsed and fed in order. The
 new  `git_config()` only guarantees precedence order for variables with the

s/\s+/ /

 same name.

 Also `funcname` variable is deprecated and not documented properly.
 `xfuncname` is mentioned in the docs and takes precedence over `funcname`.
 Instead of removing `funcname` variable, enforce `xfuncname` precedence over
 `funcname` when the variables have the same subsection. Remove dependency
 that required values to be fed to userdiff_config() in parsing order for the
 test to succeed.

 Signed-off-by: Tanay Abhra tanay...@gmail.com
 ---
 Note: this the only test that failed for the new git_config() rewrite.

  userdiff.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

 diff --git a/userdiff.c b/userdiff.c
 index fad52d6..a51bc89 100644
 --- a/userdiff.c
 +++ b/userdiff.c
 @@ -2,6 +2,7 @@
  #include userdiff.h
  #include cache.h
  #include attr.h
 +#include string-list.h

  static struct userdiff_driver *drivers;
  static int ndrivers;
 @@ -211,9 +212,12 @@ int userdiff_config(const char *k, const char *v)
 struct userdiff_driver *drv;
 const char *name, *type;
 int namelen;
 +   char *subsection = NULL;
 +   static struct string_list xflag = STRING_LIST_INIT_DUP;

 if (parse_config_key(k, diff, name, namelen, type) || !name)
 return 0;
 +   subsection = xstrndup(name, namelen);

 drv = userdiff_find_by_namelen(name, namelen);
 if (!drv) {
 @@ -224,10 +228,16 @@ int userdiff_config(const char *k, const char *v)
 drv-binary = -1;
 }

 -   if (!strcmp(type, funcname))
 +   if (!strcmp(type, funcname)  
 !unsorted_string_list_has_string(xflag, subsection)) {
 +   free (subsection);
 return parse_funcname(drv-funcname, k, v, 0);
 -   if (!strcmp(type, xfuncname))
 +   }
 +   if (!strcmp(type, xfuncname)) {
 +   string_list_append(xflag, subsection);
 +   free (subsection);
 return parse_funcname(drv-funcname, k, v, REG_EXTENDED);
 +   }
 +   free(subsection);
 if (!strcmp(type, binary))
 return parse_tristate(drv-binary, k, v);
 if (!strcmp(type, command))
 --
 1.9.0.GIT
--
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


Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`

2014-07-23 Thread Junio C Hamano
Tanay Abhra tanay...@gmail.com 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
 previously and worked only because values were parsed and fed in order.

The above is hard to understand.  Do you mean that the old code and
test used whichever (between funcname and xfuncname) appeared last
in the configuration file?

For example, if I had

diff.foo.xfuncname Beer$

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$

With the last one of xfuncname or funcname wins rule, I do not
have to worry about having xfuncname in ~/.gitconfig when I do so,
but with xfuncname is stronger than funcname rule, it suddenly
forces me to go back and check if I have something stronger in my
lower-precedence configuration file (i.e. ~/.gitconfig) when I am
trying to override with a higher-precedence configuration file
(i.e. the project-specific .git/config).

If that is what this patch is trying to change, I am not sure if I
agree that is a good change.  They are two ways to spell the same
information, and I would find it more natural if a later funcname
spelled in BRE allowed me to override an earlier xfuncname spelled
in ERE.

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