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-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, 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 60C2D1F8C8 for ; Fri, 24 Sep 2021 21:59:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344190AbhIXWBB (ORCPT ); Fri, 24 Sep 2021 18:01:01 -0400 Received: from cloud.peff.net ([104.130.231.41]:54976 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344237AbhIXWBB (ORCPT ); Fri, 24 Sep 2021 18:01:01 -0400 Received: (qmail 19843 invoked by uid 109); 24 Sep 2021 21:59:23 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Fri, 24 Sep 2021 21:59:23 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 14058 invoked by uid 111); 24 Sep 2021 21:59:23 -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; Fri, 24 Sep 2021 17:59:23 -0400 Authentication-Results: peff.net; auth=none Date: Fri, 24 Sep 2021 17:59:22 -0400 From: Jeff King To: Junio C Hamano Cc: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , git@vger.kernel.org, The Grey Wolf , "Randall S . Becker" Subject: Re: [PATCH] config: add an includeIf.env{Exists,Bool,Is,Match} Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Fri, Sep 24, 2021 at 02:28:29PM -0700, Junio C Hamano wrote: > > But as you note, "=" is somewhat problematic, and without that we can't > > use the "usual" operators. Plus there's no usual operator for globbing. ;) > > So embedding it in the name is fine by me (and mostly a bikeshed thing > > anyway). > > Perhaps. I am not sure if we deeply care about "git -c var=val" in > this case, especially since this is part of includeif, though. It > may be more important to keep the syntax useful and extensible for > everyday use than for one-off "git -c" testing. Yeah, see my comments later in that mail. :) > > I agree we don't really need a "/i" variant here. > > Case insensitive environment variable names, no, but case > insensitive matching of values, maybe? But I'd be happy to see us > start very minimally (even just envEQ alone without any other > frills, or optionally envNE to negate it, would be fine by me). Yeah, as long as we leave the door open syntactically, I think it is OK. > > Should we allow whitespace around key names and values? E.g.: > > > > [includeIf "env: FOO: bar"] > > > > is IMHO more readable (even more so if we had infix operators like > > "=="). > > This asserts what? FOO=" bar"? Whoops, that should have been "envIs", asserting that $FOO contains "bar". As I said, I think it matters more with the infix operators, as: [includeIf "env:FOO == bar"] is more readable than: [includeIf "env:FOO==bar"] But I do think: [includeIf "envIs:FOO:bar"] is harder to read than even: [includeIf "envIs:FOO: bar"] -Peff