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

[Derrick Stolee <stolee@gmail.com>]

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."

Thanks,
-Stolee