{"thread":{"id":"55337","subject":"Re: Extra blank lines in \"git status\" output have been reduced","startedAt":"2021-03-17T10:24:06Z","lastAt":"2021-03-17T21:28:57Z","messageCount":4,"participants":["Pete Boere","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"419453","messageId":"CAF8W_bFzE8strSWc0_eABdyfCxA+0CA6ph_uXgSyT7YRU-jO6A@mail.gmail.com","threadId":"55337","inReplyTo":null,"subject":"Re: Extra blank lines in \"git status\" output have been reduced","fromName":"Pete Boere","fromEmail":"pete@duel.me","sentAt":"2021-03-17T10:22:50Z","receivedAt":"2021-03-17T10:24:06Z","isPatch":false,"sender":{"key":"pete@duel.me","avatar":null},"body":"With the release of v2.23 I have noticed from the commit:\n7b098429355bb3271f9ffdf73b97f2ef82794fea\n\nWith message:\n\"Extra blank lines in \"git status\" output have been reduced.\"\n\nhttps://git.furworks.de/opensourcemirror/git/commit/7b098429355bb3271f9ffdf73b97f2ef82794fea\n\nIs there any chance of adding them back? The changed layout has been\nthrowing me off ever since upgrading.\n\nThanks\nPete Boere\n"},{"id":"419541","messageId":"xmqqo8fhtvst.fsf@gitster.g","threadId":"55337","inReplyTo":"CAF8W_bFzE8strSWc0_eABdyfCxA+0CA6ph_uXgSyT7YRU-jO6A@mail.gmail.com","subject":"Re: Extra blank lines in \"git status\" output have been reduced","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-03-17T19:38:42Z","receivedAt":"2021-03-17T19:39:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pete Boere <pete@duel.me> writes:\n\n> With the release of v2.23 I have noticed from the commit:\n> 7b098429355bb3271f9ffdf73b97f2ef82794fea\n> ...\n> Is there any chance of adding them back? The changed layout has been\n> throwing me off ever since upgrading.\n\nSorry, but it is way too late to complain, generally after a change\nhits a release, and especially after it got buried under 8 new major\nreleases.  Unless a change was an unintended side-effect that we did\nnot mean to make, in which case we would likely to fix it as a bug.\n\nAnd the change in question b2f5171e (status: remove the empty line\nafter hints, 2019-06-04) quite deliberately targets at removing\nthese extra lines [*], so no, I do not think it is reasonable to\nexpect reverting that commit that is more than a year old.\n\nYou may want to join the list discussion and stop whatever UI change\nyou find undesirable before it materializes next time.\n\n\n[Reference]\n\ncommit b2f5171ecc2feb4192acd80f5a6b05c06e099e97\nAuthor: John Lin <johnlinp@gmail.com>\nDate:   Tue Jun 4 07:02:21 2019 -0700\n\n    status: remove the empty line after hints\n    \n    Before this patch, there is inconsistency between the status\n    messages with hints and the ones without hints: there is an\n    empty line between the title and the file list if hints are\n    presented, but there isn't one if there are no hints.\n    \n    This patch remove the inconsistency by removing the empty\n    lines even if hints are presented.\n"},{"id":"419546","messageId":"YFJkJvJdO5XsrvO/@coredump.intra.peff.net","threadId":"55337","inReplyTo":"xmqqo8fhtvst.fsf@gitster.g","subject":"Re: Extra blank lines in \"git status\" output have been reduced","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-03-17T20:18:46Z","receivedAt":"2021-03-17T20:19:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 17, 2021 at 12:38:42PM -0700, Junio C Hamano wrote:\n\n> Pete Boere <pete@duel.me> writes:\n> \n> > With the release of v2.23 I have noticed from the commit:\n> > 7b098429355bb3271f9ffdf73b97f2ef82794fea\n> > ...\n> > Is there any chance of adding them back? The changed layout has been\n> > throwing me off ever since upgrading.\n> \n> Sorry, but it is way too late to complain, generally after a change\n> hits a release, and especially after it got buried under 8 new major\n> releases.  Unless a change was an unintended side-effect that we did\n> not mean to make, in which case we would likely to fix it as a bug.\n> \n> And the change in question b2f5171e (status: remove the empty line\n> after hints, 2019-06-04) quite deliberately targets at removing\n> these extra lines [*], so no, I do not think it is reasonable to\n> expect reverting that commit that is more than a year old.\n> \n> You may want to join the list discussion and stop whatever UI change\n> you find undesirable before it materializes next time.\n\nIf we discover later that some portion of users prefer an older\nbehavior, it may be reasonable to build on top with a config option to\nallow selecting the old or the new. The inputs to \"may be reasonable\"\nthere are:\n\n  - how big is the code burden to support both behaviors? In this case,\n    I don't think it's too bad; it's restoring the old newlines with a\n    conditional\n\n  - how many people would actually care enough to set the option? Even\n    without a lot of code, each option is _some_ burden to carry, both\n    in the code and in the overall complexity of the interface. I'm less\n    convinced in this particular case that a lot of people care (given a\n    single comment after many releases), but perhaps those interested in\n    the change could produce data (note I said \"data\", not \"argue more\n    vigorously\" ;) ).\n\n    It might help justify such an option if it applied in more places.\n    E.g., an option for \"I prefer the look of lots of whitespace in\n    messages\" versus \"I prefer a more compact look\".\n\n-Peff\n"},{"id":"419586","messageId":"xmqqft0ttqqf.fsf@gitster.g","threadId":"55337","inReplyTo":"YFJkJvJdO5XsrvO/@coredump.intra.peff.net","subject":"Re: Extra blank lines in \"git status\" output have been reduced","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-03-17T21:28:08Z","receivedAt":"2021-03-17T21:28:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Mar 17, 2021 at 12:38:42PM -0700, Junio C Hamano wrote:\n> ...\n>> You may want to join the list discussion and stop whatever UI change\n>> you find undesirable before it materializes next time.\n>\n> If we discover later that some portion of users prefer an older\n> behavior, it may be reasonable to build on top with a config option to\n> allow selecting the old or the new.\n\nTrue.  I do not think this one passes the bar, as the porcelain UI\nis subject to change, and it is not worth flipping and flopping\nevery few years.\n\n>   - how big is the code burden to support both behaviors? In this case,\n>     I don't think it's too bad; it's restoring the old newlines with a\n>     conditional\n\nAccumulated little cuts will start hurting someday, though.\n\nI think the change was done to make the output consistent between\ntwo cases (with or without \"use X to do Y\" hints), so it won't be\nsufficient to conditionally revert with a switch.  An option to add\nthese blank lines back would also have to add extra blank lines to\nplaces where there was (and is) no blank line, so it is more like a\nnew development than a partial reversion.\n\ncf. https://lore.kernel.org/git/?q=d%3A20190415..20190615+f%3Ajohnlinp%40gmail.com\n\n>   - how many people would actually care enough to set the option? Even\n>     without a lot of code, each option is _some_ burden to carry, both\n>     in the code and in the overall complexity of the interface. I'm less\n>     convinced in this particular case that a lot of people care (given a\n>     single comment after many releases), but perhaps those interested in\n>     the change could produce data (note I said \"data\", not \"argue more\n>     vigorously\" ;) ).\n\n;-)\n"}]}