Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`
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`
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`
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`
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`
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`
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`
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`
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`
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`
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`
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`
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`
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`
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
[PATCH 5/7] enforce `xfuncname` precedence over `funcname`
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 new `git_config()` only guarantees precedence order for variables with the 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`
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`
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`
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