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

2 messages, 2 authors, 2021-03-17 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2021-03-17 19:39:43

Pete Boere [off-list ref] writes:
With the release of v2.23 I have noticed from the commit:
7b098429355bb3271f9ffdf73b97f2ef82794fea
...
Is there any chance of adding them back? The changed layout has been
throwing me off ever since upgrading.
Sorry, but it is way too late to complain, generally after a change
hits a release, and especially after it got buried under 8 new major
releases.  Unless a change was an unintended side-effect that we did
not mean to make, in which case we would likely to fix it as a bug.

And the change in question b2f5171e (status: remove the empty line
after hints, 2019-06-04) quite deliberately targets at removing
these extra lines [*], so no, I do not think it is reasonable to
expect reverting that commit that is more than a year old.

You may want to join the list discussion and stop whatever UI change
you find undesirable before it materializes next time.


[Reference]

commit b2f5171ecc2feb4192acd80f5a6b05c06e099e97
Author: John Lin [off-list ref]
Date:   Tue Jun 4 07:02:21 2019 -0700

    status: remove the empty line after hints
    
    Before this patch, there is inconsistency between the status
    messages with hints and the ones without hints: there is an
    empty line between the title and the file list if hints are
    presented, but there isn't one if there are no hints.
    
    This patch remove the inconsistency by removing the empty
    lines even if hints are presented.

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

From: Jeff King <hidden>
Date: 2021-03-17 20:19:52

On Wed, Mar 17, 2021 at 12:38:42PM -0700, Junio C Hamano wrote:
Pete Boere [off-list ref] writes:
quoted
With the release of v2.23 I have noticed from the commit:
7b098429355bb3271f9ffdf73b97f2ef82794fea
...
Is there any chance of adding them back? The changed layout has been
throwing me off ever since upgrading.
Sorry, but it is way too late to complain, generally after a change
hits a release, and especially after it got buried under 8 new major
releases.  Unless a change was an unintended side-effect that we did
not mean to make, in which case we would likely to fix it as a bug.

And the change in question b2f5171e (status: remove the empty line
after hints, 2019-06-04) quite deliberately targets at removing
these extra lines [*], so no, I do not think it is reasonable to
expect reverting that commit that is more than a year old.

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. The inputs to "may be reasonable"
there are:

  - 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

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

    It might help justify such an option if it applied in more places.
    E.g., an option for "I prefer the look of lots of whitespace in
    messages" versus "I prefer a more compact look".

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help