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

[Derrick Stolee <stolee@gmail.com>]

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,
-Stolee