[updated subject, as we are very far off the original topic] On Wed, Aug 14, 2013 at 07:00:58AM -0700, Junio C Hamano wrote:
> > > This whole discussion is basically implementing conditional config. > > > [...] The problem is that it would be tricky to do in a > > > backwards-compatible way. > > > > That could be done with "conditional comments" like > > > > # if <some-condition> then > > [core] > > pager = less > > # endif > > > > That's rather ugly, and the implementation would be even more ugly, but > > backward-compatible. > > I highly doubt that you would want to be "backward compatible" in this > case, though. The section of the configuration you are enclosing the > new if/endif syntax may be understood only by newer Git (e.g. imagine > core.pager is still bool-only today), and older Git that do not > understand if/endif syntax will happily read that section and choke on > it, no? I would think the ideal behavior would be for existing implementations to just not include the conditional section. If we take the conditional by default in existing versions of git (i.e., the behavior of Matthieu's proposal), then any "do this only if version X or greater" conditional is going to be inconsistent (it will be true for old versions, not true for versions which understand conditionals but pre-date X, and then true again for the actual versions you want). Likewise, if we introduce some new non-backwards-compatible syntax that existing Git chokes on, then you have created a new compatibility problem. You cannot use older versions of git, which is the exact problem a version conditional is trying to solve. That is one of the reasons that include.path is designed as it is; old versions accept it and do nothing (unless you specifically ask for it as a value). And likewise, include.*.path will do nothing for existing versions of git. Or hmm. Maybe that is what you mean by "choke on it". Choke on the invalid config, not on the new syntax. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
