From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 715041F4B4 for ; Wed, 9 Dec 2020 16:27:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730238AbgLIQYs (ORCPT ); Wed, 9 Dec 2020 11:24:48 -0500 Received: from cloud.peff.net ([104.130.231.41]:55658 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728751AbgLIQYs (ORCPT ); Wed, 9 Dec 2020 11:24:48 -0500 Received: (qmail 18378 invoked by uid 109); 9 Dec 2020 16:24:04 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Wed, 09 Dec 2020 16:24:04 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 16587 invoked by uid 111); 9 Dec 2020 16:24:03 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Wed, 09 Dec 2020 11:24:03 -0500 Authentication-Results: peff.net; auth=none Date: Wed, 9 Dec 2020 11:24:03 -0500 From: Jeff King To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Cc: Patrick Steinhardt , git@vger.kernel.org, Junio C Hamano , "brian m. carlson" , Philip Oakley Subject: Re: [PATCH v4 2/6] config: add new way to pass config via `--config-env` Message-ID: References: <766ffe31a6f14c55d1b58a8f53edbb7f731b1b24.1607514692.git.ps@pks.im> <871rfzxctq.fsf@evledraar.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <871rfzxctq.fsf@evledraar.gmail.com> Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Wed, Dec 09, 2020 at 03:40:17PM +0100, Ævar Arnfjörð Bjarmason wrote: > > +--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`. > > Okey, because "-c foo.bar" (true) "-c foo.bar=" is the empty string, but > that doesn't make sene with "--config-env". Also the whole part about > --type=bool is just confusing, because it's referring to `-c`'s magic > behavior when it comes to `bool` which we don't have here. Yeah, I agree. > I think it's also worth describing what this is for & what the > limitations are. Maybe: Agreed, and the text you gave looks reasonable. Another reason to use it is that it will (if we add the patches I just sent on top) avoid the key/value ambiguity with equals in the section name. > Not something new, and maybe not something for this series, but I wish > -c and --config-env would document this limitation that we support "=" > in keys in config, but not via those parameters. Yeah. If we add in my patches, then the limitation is gone here (but we should mention the limitation on the environment variable name). I stopped short of adding a variant of "-c" that avoids the ambiguity. I'm certainly not opposed to one if somebody wants to do it, but I think documenting the current limitation makes sense in the meantime (and we should do it in this series while we're thinking about it). -Peff