From: Jeff King Date: Wed, 09 Dec 2020 16:10:04 GMT Subject: Re: [PATCH v4 2/6] config: add new way to pass config via `--config-env` Message-ID: In-Reply-To: <766ffe31a6f14c55d1b58a8f53edbb7f731b1b24.1607514692.git.ps@pks.im> On Wed, Dec 09, 2020 at 12:52:26PM +0100, Patrick Steinhardt wrote: > Co-authored-by: Jeff King > Signed-off-by: Patrick Steinhardt In case we want it, this is also: Signed-off-by: Jeff King > +--config-env==:: > + Pass a configuration parameter to the command. The > + given will be replaced with the contents of the environment > + variable of that name. In contrast to `-c`, an envvar must > + always be given and exist in the environment. Passing an > + environment variable with empty value will set to the > + empty string which `git config --type=bool` will convert to > + `false`. I agree with Ævar that we probably should keep an empty variable as the empty string. I think some options use an empty string to clear a list (e.g., push.pushOption), and I'm not sure how they'd react to a bool instead. It would be nice to also have a way to do the implicit-bool thing, but I don't think it's strictly necessary (it's always correct to put the string "true" into the variable instead). I think we should also document that can't contain an "=" sign. Of course using strrchr() here doesn't help much with just this patch, because we flatten the string before stuffing it into $GIT_CONFIG_PARAMETERS, so the reading side would mis-parse it. But here's a fix for that. I built it on top of your whole series, since you touched some of the related functions, but it could easily be rebased onto just this part. [1/3]: quote: make sq_dequote_step() a public function [2/3]: config: parse more robust format in GIT_CONFIG_PARAMETERS [3/3]: config: store "git -c" variables using more robust format config.c | 118 +++++++++++++++++++++++++++++++++++++--------- quote.c | 15 ++++-- quote.h | 18 ++++++- t/t1300-config.sh | 60 +++++++++++++++++++++++ 4 files changed, 183 insertions(+), 28 deletions(-) -Peff