Jeff King <p...@peff.net> writes: > Yeah, this is what I had in mind. My only reservation would be that we > need to make sure it is clear that this applies only to keys marked as > taking a "pathname" type in the documentation. I'm suspect there are > ones that are logically paths but do not currently do the expansion, but > the wording above makes it sound like any pathname-like thing does.
Yeah, my initial draft phrased it more like how we describe boolean, but somehow the language used there felt awkward to me. With "A variable that take a pathname value", the users who read it would find "ones that are logically paths but do not do the expansion" and file a bug. We'd resolve each of them by seeing if the documentation says the variable does take a pathname, and adjust either the documentation (if the value for the variable should not be expanded but the documentation hints it might be a pathname-like thing, clarify that it is not pathname-like at all) or the code (if the value for the variable should be expanded but we forgot, we call the user_path() function). > Alternatively, it might be worth going through the list to make sure all > paths use git_config_pathname() internally. I was hoping that with the patch we can farm out the bug-hunting process to the end users. > Brian asked earlier if the "no expansion" was an intentional > policy, but it's not. It's just that pathname expansion came much > later, and config keys were ported over to it one by one as people > found it useful to do so. Yes, that matches the actual order of events. -- 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
