Re: Extra blank lines in "git status" output have been reduced

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 17, 2021, 21:28 UTC
Message-ID: <xmqqft0ttqqf.fsf@gitster.g>
In-Reply-To: <YFJkJvJdO5XsrvO/@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

> On Wed, Mar 17, 2021 at 12:38:42PM -0700, Junio C Hamano wrote:
> ...
>> You may want to join the list discussion and stop whatever UI change
>> you find undesirable before it materializes next time.
>
> If we discover later that some portion of users prefer an older
> behavior, it may be reasonable to build on top with a config option to
> allow selecting the old or the new.

True. I do not think this one passes the bar, as the porcelain UI is subject to change, and it is not worth flipping and flopping every few years.

>   - how big is the code burden to support both behaviors? In this case,
>     I don't think it's too bad; it's restoring the old newlines with a
>     conditional

Accumulated little cuts will start hurting someday, though.

I think the change was done to make the output consistent between two cases (with or without "use X to do Y" hints), so it won't be sufficient to conditionally revert with a switch. An option to add these blank lines back would also have to add extra blank lines to places where there was (and is) no blank line, so it is more like a new development than a partial reversion.

cf. https://lore.kernel.org/git/?q=d%3A20190415..20190615+f%3Ajohnlinp%40gmail.com

Show 7 quoted lines

>   - how many people would actually care enough to set the option? Even
>     without a lot of code, each option is _some_ burden to carry, both
>     in the code and in the overall complexity of the interface. I'm less
>     convinced in this particular case that a lot of people care (given a
>     single comment after many releases), but perhaps those interested in
>     the change could produce data (note I said "data", not "argue more
>     vigorously" ;) ).

;-)