Re: [Bug report] includeIf config is not displayed in normal directories

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Dec 15 2020, Stuart MacDonald wrote:

> Hello,
>
> I've seen this thread:
> https://public-inbox.org/git/F55DC360-9C1E-45B9-B8BA-39E1001BD620@gmail.com/t/#u

[I took the liberty of CC-ing the original thread participants & adding
the Message-Id's to the "References" header, hopefully the archive will
thread it and this together for future spelunking]

> and respectfully disagree with the conclusion. Conditionally included
> configuration can contain items like core.sshCommand that are required
> for git clone while in a normal non-git directory. These should be
> displayed properly so users know what configuration they are operating
> with.
>
> Also, conditionally included config is acted upon despite not being
> displayed. This makes tracking down problems much more difficult.
>
> Further, most complaints online are about user.name and user.email not
> being displayed correctly. If those items are in ~/.gitconfig, then
> they are displayed in a normal non-git directory by normal git config
> commands. This makes conditionally included configuration display
> inconsistent with regular configuration display. Inconsistency is bad
> and should be fixed.
>
> See 'git bugreport' attached for further information, reproduction steps, etc.

As the person with the last reply in that old thread & only a vague
recollection of it until I re-read it now: please don't take a "why
would you want this" question as dismissive of the use-case, but in
invite to tease out some of the nuances.

It's often easy to vaguely conceptualize a feature, but the hard work is
dealing with all the edge cases & emergent properties of something like
new IncludeIf semantics.

There's two interesting questions here: Is the current feature buggy (or
just has surprised but ultimately consistent & correct semantics), and
could we have some new IncludeIf use-case that covers use-case Y, where
now we can only do X?

Junio covered that in more detail in his reply.

Neither you nor anyone reading this from the archive later should read
that thread (or this one) as some refusal of a feature that does Y.

Whether we can have that ultimately depends on whether someone's going
to invest the time in coming up with patches for it, and in writing
those patches will either figure out all the expected & unexpected edge
cases involved & get past them, or not.

But it's not a "no" until that point (and not even then, maybe we can
keep the general idea of Y, but have Z which is mostly the same & works
for most people), it's just "nobody's really worked on it yet".