Re: [PATCH 2/2] branch, for-each-ref: add option to omit empty lines

[Jeff King <peff@peff.net>]

On Thu, Apr 06, 2023 at 11:20:03AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> 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