Re: [PATCH v4] config: add conditional include

From: Duy Nguyen <pclouds@gmail.com>
Date: Aug 22, 2016, 13:09 UTC
Message-ID: <CACsJy8BNP8GDRxDGTQwcYWTovN9o11TCkUJ28=5zav3QnGv9nQ@mail.gmail.com>
In-Reply-To: <vpqr39harit.fsf@anie.imag.fr>

On Mon, Aug 22, 2016 at 7:59 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 31 quoted lines

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Sun, Aug 21, 2016 at 4:08 AM, Jakub Narębski <jnareb@gmail.com> wrote:
>>> W dniu 19.08.2016 o 15:54, Jeff King pisze:
>>>> On Sat, Aug 13, 2016 at 03:40:59PM +0700, Duy Nguyen wrote:
>>>>
>>>>> Ping..
>>>>
>>>> There was some discussion after v4. I think the open issues are:
>>>>
>>>>   - the commit message is rather terse (it should describe motivation,
>>>>     and can refer to the docs for the "how")
>>>>
>>>>   - the syntax might be more clear as:
>>>>
>>>>        [include-if "gitdir:..."]
>>>>
>>>>     or
>>>>
>>>>        [include "gitdir-is:..."]
>>>
>>> Or
>>>
>>>          [include "if-gitdir:..."]
>>
>> I like this one. I can re-roll to address the first two bullet point,
>> if the last one, the open question, will not become a blocker later
>> on.
>
> I think the syntax should be design to allow arbitrary boolean
> expression later if needed.

I would be against that. We may extend it more in future, but it should be under control, not full boolean expressions.

Show 17 quoted lines

> Then, I prefer one of
>
>   [include-if "gitdir-is:..."]
>   [include    "gitdir-is:..."]
>
> because it may later be extended to e.g.
>
>   [include-if "not(gitdir-is:...)"]
>   [include-if "gitdir-matches:regex"]
>   [include-if "gitdir-is:... and git-version-greater:2.9"]
>   ...
>
> I actually already use "conditional include on version number" because I
> use push.default=upstream which makes older versions of Git crash, but
> fortunately these versions of Git also ignore the "include" directive so
> having this push.default=upstream in an included file works. It's a
> hack, it worked once but it won't work again.

We probably have a way to stop old git from reading new git's features, including ones in config files: the config group extensions.*. Assuming that "[include "blah"]" is new stuff, git can be taught to accept that only when extensions.blah is present (which old git would bail). It discourages adding too many fancy features (because extensions.* in your config file would be a mess), which is IMO a good point.

-- 
Duy