From: Junio C Hamano Date: Fri, 29 Apr 2016 17:27:30 GMT Subject: Re: [PATCH 2/2] http: expand http.cookieFile as a path Message-ID: In-Reply-To: <20160429171631.GA29571@sigill.intra.peff.net> Jeff King 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.