Thread (1 message) 1 message, 1 author, 2021-03-17

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

From: Junio C Hamano <hidden>
Date: 2021-03-17 21:28:57

Jeff King [off-list ref] writes:
On Wed, Mar 17, 2021 at 12:38:42PM -0700, Junio C Hamano wrote:
...
quoted
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" ;) ).
;-)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help