{"thread":{"id":"61268","subject":"[PATCH RESEND] send-email: make produced outputs more readable","startedAt":"2024-04-04T17:07:42Z","lastAt":"2024-04-04T19:40:34Z","messageCount":3,"participants":["Dragan Simic","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"492254","messageId":"62553db377c28458883b66bcdc0c58cc0f32d15b.1712250366.git.dsimic@manjaro.org","threadId":"61268","inReplyTo":null,"subject":"[PATCH RESEND] send-email: make produced outputs more readable","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-04-04T17:07:32Z","receivedAt":"2024-04-04T17:07:42Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"When sending multiple patches at once, without confirming the sending of each\npatch separately, the displayed result statuses of sending each patch become\nbunched together with the messages produced for the subsequent patch.  This\nunnecessarily makes discerning each of the result statuses a bit difficult,\nas visible in the sample output excerpt below:\n\n    ...\n    MIME-Version: 1.0\n    Content-Transfer-Encoding: 8bit\n\n    Result: 250\n    OK. Log says:\n    ...\n\nAs visible above, bunching the \"Result: <status-code>\" lines together with\nthe messages produced for the subsequent patch makes the output unreadable.\nThus, let's add a newline after each displayed result status, to make the\noutputs more readable, as visible in the sample output excerpt below:\n\n    ...\n    MIME-Version: 1.0\n    Content-Transfer-Encoding: 8bit\n\n    Result: 250\n\n    OK. Log says:\n    ...\n\nThis change also adds a newline after the last produced result status, which\nmay be seen as redundant.  Though, it doesn't look too bad, and making that\nlast newline not displayed would make the code much more complex, which would\nnot be worth neither the time and effort now, nor the additional maintenance\nburden in the future.\n\nWhile there, remove one spotted stray newline in the code.\n\nSigned-off-by: Dragan Simic <dsimic@manjaro.org>\n---\n\nNotes:\n     * send-email: make produced outputs more readable by separating\n       the result statuses from the subsequent patch outputs\n    \n    This is a resubmission of the patch I submitted about a week and a half\n    ago. [1]  The patch subject in the original submission was selected in\n    a bit unfortunate way, which this submission corrects, and also improves\n    the patch description a bit.  There are no changes to the patch itself.\n    \n    [1] https://lore.kernel.org/git/6ee28707b9eb8bd8fdfc8756c351455c6bc3bb62.1711447365.git.dsimic@manjaro.org/\n\n git-send-email.perl | 5 ++---\n 1 file changed, 2 insertions(+), 3 deletions(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 821b2b3a135a..62505ab2707c 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1576,7 +1576,6 @@ sub send_message {\n \t\tprint $sm \"$header\\n$message\";\n \t\tclose $sm or die $!;\n \t} else {\n-\n \t\tif (!defined $smtp_server) {\n \t\t\tdie __(\"The required SMTP server is not properly defined.\")\n \t\t}\n@@ -1686,9 +1685,9 @@ sub send_message {\n \t\tprint $header, \"\\n\";\n \t\tif ($smtp) {\n \t\t\tprint __(\"Result: \"), $smtp->code, ' ',\n-\t\t\t\t($smtp->message =~ /\\n([^\\n]+\\n)$/s), \"\\n\";\n+\t\t\t\t($smtp->message =~ /\\n([^\\n]+\\n)$/s), \"\\n\\n\";\n \t\t} else {\n-\t\t\tprint __(\"Result: OK\\n\");\n+\t\t\tprint __(\"Result: OK\\n\\n\");\n \t\t}\n \t}\n \n"},{"id":"492262","messageId":"xmqqy19tylrm.fsf@gitster.g","threadId":"61268","inReplyTo":"62553db377c28458883b66bcdc0c58cc0f32d15b.1712250366.git.dsimic@manjaro.org","subject":"Re: [PATCH RESEND] send-email: make produced outputs more readable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-04-04T19:23:57Z","receivedAt":"2024-04-04T19:24:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dragan Simic <dsimic@manjaro.org> writes:\n\n> Notes:\n>      * send-email: make produced outputs more readable by separating\n>        the result statuses from the subsequent patch outputs\n>     \n>     This is a resubmission of the patch I submitted about a week and a half\n>     ago. [1]  The patch subject in the original submission was selected in\n>     a bit unfortunate way, which this submission corrects, and also improves\n>     the patch description a bit.  There are no changes to the patch itself.\n\nI tried to cram a bit more information than \"output more readable\"\nthat lacks in what way the result is easier to read.\n\n    send-email: make boundaries between messages easier to spot\n\nperhaps?\n\n> diff --git a/git-send-email.perl b/git-send-email.perl\n> index 821b2b3a135a..62505ab2707c 100755\n> --- a/git-send-email.perl\n> +++ b/git-send-email.perl\n> @@ -1576,7 +1576,6 @@ sub send_message {\n>  \t\tprint $sm \"$header\\n$message\";\n>  \t\tclose $sm or die $!;\n>  \t} else {\n> -\n>  \t\tif (!defined $smtp_server) {\n>  \t\t\tdie __(\"The required SMTP server is not properly defined.\")\n>  \t\t}\n> @@ -1686,9 +1685,9 @@ sub send_message {\n>  \t\tprint $header, \"\\n\";\n>  \t\tif ($smtp) {\n>  \t\t\tprint __(\"Result: \"), $smtp->code, ' ',\n> -\t\t\t\t($smtp->message =~ /\\n([^\\n]+\\n)$/s), \"\\n\";\n> +\t\t\t\t($smtp->message =~ /\\n([^\\n]+\\n)$/s), \"\\n\\n\";\n>  \t\t} else {\n> -\t\t\tprint __(\"Result: OK\\n\");\n> +\t\t\tprint __(\"Result: OK\\n\\n\");\n>  \t\t}\n\nIt would be nicer to instead add a single separate\n\n\t\tprint \"\\n\";\n\nafter these if/else alternatives, without touching the existing\nmessage lines, I would think.  That way, existing message\ntranslations do not have to change.\n\nIf we were to change the translatable string anyway, it would be\neven better to remove the newline from the translatable part of the\nmessage, rendering the thing to:\n\n\tif ($smtp) {\n\t\tprint __(\"Result: \"), ..., ($smtp->message =~ /.../);\n  \t} else {\n\t\tprint __(\"Result: OK\");\n\t}\n\tprint \"\\n\\n\";\n\nStrictly speaking, that is an orthogonal clean-up, so it may have to\nmake it into two patch series, one for preliminary clean-up \"to\nexcise terminating newline out of translatable strings\" patch that\nadds a separate print that adds a single newline, plus the \"make it\neasier to spot where a message ends and another one starts\" patch\nthat makes the new print statement that adds a single newline to\ninstead add two.  In a patch as simple as this one, however, I think\nkilling two birds with a stone, i.e., directly go to the \"if we were\nto change the translatable string anyway\" final shape in a single\npatch, would be fine.\n\nThanks.\n\n\n"},{"id":"492264","messageId":"44ed7af52e2968993d9b2b99faec1f64@manjaro.org","threadId":"61268","inReplyTo":"xmqqy19tylrm.fsf@gitster.g","subject":"Re: [PATCH RESEND] send-email: make produced outputs more readable","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-04-04T19:40:32Z","receivedAt":"2024-04-04T19:40:34Z","isPatch":true,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"Hello Junio,\n\nOn 2024-04-04 21:23, Junio C Hamano wrote:\n> Dragan Simic <dsimic@manjaro.org> writes:\n> \n>> Notes:\n>>      * send-email: make produced outputs more readable by separating\n>>        the result statuses from the subsequent patch outputs\n>> \n>>     This is a resubmission of the patch I submitted about a week and a \n>> half\n>>     ago. [1]  The patch subject in the original submission was \n>> selected in\n>>     a bit unfortunate way, which this submission corrects, and also \n>> improves\n>>     the patch description a bit.  There are no changes to the patch \n>> itself.\n> \n> I tried to cram a bit more information than \"output more readable\"\n> that lacks in what way the result is easier to read.\n> \n>     send-email: make boundaries between messages easier to spot\n> \n> perhaps?\n\nLooking good to me, will use that as the patch subject in v2.\n\n>> diff --git a/git-send-email.perl b/git-send-email.perl\n>> index 821b2b3a135a..62505ab2707c 100755\n>> --- a/git-send-email.perl\n>> +++ b/git-send-email.perl\n>> @@ -1576,7 +1576,6 @@ sub send_message {\n>>  \t\tprint $sm \"$header\\n$message\";\n>>  \t\tclose $sm or die $!;\n>>  \t} else {\n>> -\n>>  \t\tif (!defined $smtp_server) {\n>>  \t\t\tdie __(\"The required SMTP server is not properly defined.\")\n>>  \t\t}\n>> @@ -1686,9 +1685,9 @@ sub send_message {\n>>  \t\tprint $header, \"\\n\";\n>>  \t\tif ($smtp) {\n>>  \t\t\tprint __(\"Result: \"), $smtp->code, ' ',\n>> -\t\t\t\t($smtp->message =~ /\\n([^\\n]+\\n)$/s), \"\\n\";\n>> +\t\t\t\t($smtp->message =~ /\\n([^\\n]+\\n)$/s), \"\\n\\n\";\n>>  \t\t} else {\n>> -\t\t\tprint __(\"Result: OK\\n\");\n>> +\t\t\tprint __(\"Result: OK\\n\\n\");\n>>  \t\t}\n> \n> It would be nicer to instead add a single separate\n> \n> \t\tprint \"\\n\";\n> \n> after these if/else alternatives, without touching the existing\n> message lines, I would think.  That way, existing message\n> translations do not have to change.\n> \n> If we were to change the translatable string anyway, it would be\n> even better to remove the newline from the translatable part of the\n> message, rendering the thing to:\n> \n> \tif ($smtp) {\n> \t\tprint __(\"Result: \"), ..., ($smtp->message =~ /.../);\n>   \t} else {\n> \t\tprint __(\"Result: OK\");\n> \t}\n> \tprint \"\\n\\n\";\n> \n> Strictly speaking, that is an orthogonal clean-up, so it may have to\n> make it into two patch series, one for preliminary clean-up \"to\n> excise terminating newline out of translatable strings\" patch that\n> adds a separate print that adds a single newline, plus the \"make it\n> easier to spot where a message ends and another one starts\" patch\n> that makes the new print statement that adds a single newline to\n> instead add two.  In a patch as simple as this one, however, I think\n> killing two birds with a stone, i.e., directly go to the \"if we were\n> to change the translatable string anyway\" final shape in a single\n> patch, would be fine.\n\nThank you very much for such a detailed review!  I also think that\nputting everything into a single patch is a better option, because\nthe changes are rather small.  Will do that in v2.\n"}]}