Jeff King <p...@peff.net> writes: > I think that's syntactically invalid. At any rate, there are clearly > three options for setting a bit: > > 1. In the section header (+include, or Ævar's includeIf suggestion). > > 2. In another key (which looks pretty clean, but does introduce > ordering constraints). > > 3. In the key name (maybePath or similar). > > I don't have a huge preference between them.
What's the longer term goal for the endgame? Is it acceptable that include.path will stay to be "optional include" for compatibility with users' existing configuration files, and include.requiredpath or similar gets introduced to allow people who want to get warned? Or do we want the usual multi-step deprecation dance where the first phase introduces include.maybepath and include.path starts warning against missing one, encouraging it to be rewritten to maybepath? I have mild preference against #2, as I suspect that the ordering constraints makes it harder to understand to end users. Between #1 and #3, there wouldn't be much difference, whether the endgame is "add a stricter variant that is opt in" or "migrate to a stricter default".
