> > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html