Re: [PATCH 0/3] config: allow disabling config includes

[Junio C Hamano <gitster@pobox.com>]

Derrick Stolee <stolee@gmail.com> writes:

> On 6/17/2026 2:53 PM, Junio C Hamano wrote:
>> Derrick Stolee <stolee@gmail.com> writes:
>> 
>>> On 6/11/2026 4:39 AM, Jeff King wrote:
>>>> On Tue, Jun 09, 2026 at 08:59:22AM -0400, Derrick Stolee wrote:
>>>
>>>> I'm not sure I entirely understand the problematic case, though. The
>>>> user points to in-repo config (which we already tell people is a bad
>>>> idea), and then that config breaks for some reason? Because the include
>>>> is relative and git is run from another directory?
>>>
>>>>> Or: are we venturing into territory where we don't even want to create a
>>>>> new foot-gun? If there were another way to solve the situation that I'm
>>>>> facing without these risks, then I'd be open to it. Any ideas?
>>>>
>>>> Yeah, the more I think on it, the more it seems like a foot-gun. Like I
>>>> said, I'm not sure I entirely understand the use-case. If you could
>>>> flesh out an example, that might help.
>>> The case I'm struggling with is that our build system has sandboxing
>>> restrictions to make sure the build is deterministic based on a certain
>>> number of inputs. A tool we don't control is calling Git commands and
>>> these users with included config are getting errors because the build
>>> is looking at files in the repo that are not registered as build inputs.
>>>
>>> Files within $SRCROOT/.git/ are ignored as "internal to Git" but when
>>> the users update their config to include other files, this error occurs.
>>>
>>> I'd much rather that this tool doesn't call Git at all, but I'm unable
>>> to make that change to a third-party tool. But this environment variable
>>> would make it possible to disable this behavior. And I'd also rather
>>> that these users don't use includes in this way, but they are using a
>>> checked-in file to share aliases and other quality-of-life things when
>>> a human uses Git, not "critical" settings.
>>>
>>> This series is my attempt to see if we can find a solution that enables
>>> this behavior, but maybe we've found enough concerns with the idea that
>>> we can push back on the users to say "stop doing that."
>> 
>> It seems that the thread went dark after this message.  Should I
>> take silence as an agreement, and mark the topic as retracted?
>> 
>> Thanks for an interesting discussion.
>
> Yes, consider this retracted. I saw you made that note in the What's
> Cooking email so I thought it was understood.
>
> I believe that the risk is not worth the reward here.

Thanks.  Will drop.