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