On Thu, Mar 25, 2021 at 12:05:09AM +0100, Ævar Arnfjörð Bjarmason wrote: > > As an aside, it feels like this is something we ought to be able to > > ask git-config about, rather than having a test-helper. This is > > basically "baked-in" config, and if we represented it as such, and > > parsed it into a struct just like regular config, then probably "git > > config --list --source" could be used to find it (and differentiate it > > from user-provided config). Possible downsides: > > > > 1. Would people find it confusing that "git config --list" suddenly > > gets way bigger? Maybe we'd want an "--include-baked-in" option > > or something. > > > > 2. Is the cost of parsing the config measurably bad? Obviously a > > user could provide the same content and we'd have to parse it, > > but there's a lot more rules here than most users would probably > > provide. > > Also: > > 3. Only the PATTERNS() macro translates as-is to config syntax. We > don't have a way to do what IPATTERN() does in the config syntax > currently. > > We could add a ifuncname and xifuncname or whatever for it I guess, > but currently the ICASE behavior in the C code is magic. Good point. IMHO that is something we should consider fixing independently. It was a mistake to add builtins that couldn't be replicated via the config (though I notice it happened quite a while ago, and nobody seems to have cared, so perhaps it isn't that important). I have also wondered if we should just ship a file which could be installed as /etc/gitconfig.filetypes and include it the stock /etc/gitconfig. That is effectively the same as "baked in", but hopefully makes it more clear to users how they can modify things. But all of that is somewhat orthogonal to what you're doing here. -Peff
