On Wed, Nov 18, 2020 at 02:25:32AM +0000, brian m. carlson wrote: > On 2020-11-18 at 01:59:07, Jeff King wrote: > > Yes, I think concatenating uri_encode(key) + "=" + uri_encode(value) > > would be easier to reason about, and solves the ambiguity problem. If we > > are willing to break from the existing format, it's probably a > > reasonable direction. > > We'll have to deal with embedded NULs, but other than that it seems > robust and easy to reason about. I like the proposal below better, > though. This would be easy enough to handle and fixes all the problems I currently have. > > I wondered at first how this is different from: > > > > git -c a.b.c=value foo > > > > but I guess it is meant to do the same environment-lookup? We could > > probably add: > > > > git --env-config a.b.c=ENV_VAR foo > > > > to have Git internally stick $ENV_VAR into $GIT_CONFIG_PARAMETERS. That > > avoids all of the rev-parse rigamarole, keeps the format of the > > environment variable opaque, and solves Patrick's problem of putting the > > value onto the command-line. > > Sure, that could be an option. It's the simplest, and we already know > how to handle config this way. People will be able to figure out how to > use it pretty easily. At first, this idea sounds quite interesting. But only until one realizes that it's got the exact same problem which I'm trying to solve: there's still a point in time where one can observe config values via the command line, even though that moment now is a lot shorter compared to running the "real" git command with those keys. > > It doesn't solve the ambiguity with "=" in the subsection, but IMHO that > > is not all that important a problem. > > I'm fine with saying that we don't support environment variable names > with equals signs and just going with that. It solves the ambiguity > problem and I'm not sure that they could usefully work on Unix anyway. > > Moreover, people usually use the unrestricted data in the second chunk > for URLs, which shouldn't have unquoted equals signs. You could > technically name other second fields that way, but why would you when > you could just not? > > So I'm not too worried about it either way. There's not only URLs though, but also paths in 'includeIf.*.path'. Sure, it's unlikely that paths have an equals sign embedded. But I think we should try to not paint ourselves into a corner. This problem also would be nicely solved by URI-encoding both key and value and then passing it via GIT_CONFIG_PARAMETER. Patrick
Attachment:
signature.asc
Description: PGP signature
