On Tue, Dec 15 2020, Stuart MacDonald wrote: > Hello, > > I've seen this thread: > https://public-inbox.org/git/F55DC360-9C1E-45B9-B8BA-39E1001BD620@xxxxxxxxx/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".
