On Thu, Apr 06, 2023 at 11:20:03AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > It might be enough to flip the default unconditionally (no config), but > > I think we may still want "--no-omit-empty-lines" as an escape hatch. I > > dunno. Maybe that is somehow choosing the worst of both worlds. > > It is very tempting, indeed. We can add the escape hatch and flip > the default, and only when somebody complains, come back and say > "oh, sorry, we didn't know anybody used it" and flip the default > back, perhaps? I don't think flipping back after such an incident is a good idea, as it just creates more confusion. But if the option exists, then at least you can say "oh, sorry; you can still do what you want by passing this option", rather than "oh, sorry; there's no way to get what you want". But either way, the first step before flipping any defaults is adding an option, which is what this patch is doing, so I am all for it. :) > This is a totally unrelated tangent, but it is a bit unfortunate > that with our parse-options API, it is not trivial to > > - mark that "--keep-empty-lines" and "--omit-empty-lines" toggle > the same underlying Boolean variable, > > - accept "--no-keep" and "--no-omit" as obvious synonyms for > "--omit" and "--keep", > > - have "git foo -h" listing to show "--keep" and "--omit" together, > > - omit these "--no-foo" variants from "git foo -h" listing. > > by the way. Yeah, "--no-" is special in our parser in a way that "--keep" and "--omit" aren't. It might be possible to make this pattern easier to support. OTOH, perhaps it is a sign that we are straying too far from existing patterns. It is not just parse-options.c, but also users themselves, who benefit from consistency. -Peff
