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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> 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

>   - 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" ;) ).

;-)



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux