Hi Peff, On Sat, 16 Jul 2016, Jeff King wrote: > On Sat, Jul 16, 2016 at 06:36:03PM +0200, Johannes Schindelin wrote: > > > > On Sat, Jul 16, 2016 at 03:30:45PM +0200, Johannes Schindelin wrote: > > > > > > > As an alternative solution to your problem, you could of course avoid all > > > > conditional includes. Simply by adding the include.path settings > > > > explicitly to the configs that require them. Now, that would make reasoning > > > > and trouble-shooting simple, wouldn't it? > > > > > > > > And the most beautiful aspect of it: no patch needed. > > > > > > And you can just "cat" the included files directly into your > > > .git/config. We don't even need include.path. Or ~/.gitconfig, for that > > > matter. But sometimes dynamic things are convenient. > > > > Well, apparently you are not convinced by my argument. I thought it was > > pretty sound, but if you disagree, it cannot have been... > > Heh. Don't get me wrong, I do think there's room for digging ourselves a > deep hole with conditional includes, because anything dynamic opens up a > question of _when_ it is evaluated, and in what context. So any > condition should be something that we would consider static through the > whole run of the program. Looking at the "gitdir" is right on the > borderline of that, but I think it's OK, because we already have to > invalidate any cached config when we setup the gitdir, because > "$GIT_DIR/config" will have become a new source. > > So I agree it's something we need to be thoughtful about, but I think > this particular instance is useful and probably not going to bite us. FWIW I am slightly less worried about the conditional includes (it is already a horrible mess to figure out too-long include chains now, before having conditional includes, for example). I am slightly more worried about eventually needing to introduce support for something like [if-gitdir(...):section] thisSettingIsConditional = ... or even [if (worktree==...):section] anotherConditional = ... and then having two incompatible conditional constructs, one generic, the other one specific to [include]. In other words, if we already introduce a conditional construct, I'd rather have one that could easily be used for other conditions/sections when (and if) needed. I, for one, would rather have my repository-specific overrides in one single file than having a bunch of files that are included conditionally and may need to override one another: I can see the entries much easier in the single file (and group them by section) than in the multiple files. My working memory is just too filled up with other stuff to remember the contents of the other file(s). But I guess that boils down to preference. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html