Re: [PATCH 2/2] http: expand http.cookieFile as a path

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 29, 2016, 17:27 UTC
Message-ID: <xmqqr3doz5od.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160429171631.GA29571@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

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