{"thread":{"id":"42443","subject":"[PATCH] transport, send-pack: append period to up-to-date message","startedAt":"2016-05-24T20:51:44Z","lastAt":"2016-05-26T14:16:11Z","messageCount":5,"participants":["Yong Bakos","Stefan Beller","Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"287454","messageId":"1464123104-45513-1-git-send-email-junk@humanoriented.com","threadId":"42443","inReplyTo":null,"subject":"[PATCH] transport, send-pack: append period to up-to-date message","fromName":"Yong Bakos","fromEmail":"junk@humanoriented.com","sentAt":"2016-05-24T20:51:44Z","receivedAt":"2016-05-24T20:51:44Z","isPatch":true,"sender":{"key":"junk@humanoriented.com","avatar":null},"body":"Appending a period to \"Everything up-to-date\" makes the output message\nconsistent with similar output in builtin/merge.c.\n\nSigned-off-by: Yong Bakos \n---\n builtin/send-pack.c | 2 +-\n transport.c | 2 +-\n 2 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/send-pack.c b/builtin/send-pack.c\nindex 1ff5a67..67d9304 100644\n--- a/builtin/send-pack.c\n+++ b/builtin/send-pack.c\n@@ -294,7 +294,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)\n \t}\n\n \tif (!ret && !transport_refs_pushed(remote_refs))\n-\t\tfprintf(stderr, \"Everything up-to-date\\n\");\n+\t\tfprintf(stderr, \"Everything up-to-date.\\n\");\n\n \treturn ret;\n }\ndiff --git a/transport.c b/transport.c\nindex 095e61f..53d5405 100644\n--- a/transport.c\n+++ b/transport.c\n@@ -942,7 +942,7 @@ int transport_push(struct transport *transport,\n \t\tif (porcelain && !push_ret)\n \t\t\tputs(\"Done\");\n \t\telse if (!quiet && !ret && !transport_refs_pushed(remote_refs))\n-\t\t\tfprintf(stderr, \"Everything up-to-date\\n\");\n+\t\t\tfprintf(stderr, \"Everything up-to-date.\\n\");\n\n \t\treturn ret;\n \t}\n--\n2.7.2\n"},{"id":"287455","messageId":"CAGZ79kayB59-U52oAw=13a2CAhJLsfmoD6JbAURbt0p8g8a8fg@mail.gmail.com","threadId":"42443","inReplyTo":"1464123104-45513-1-git-send-email-junk@humanoriented.com","subject":"Re: [PATCH] transport, send-pack: append period to up-to-date message","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-05-24T21:21:00Z","receivedAt":"2016-05-24T21:21:00Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, May 24, 2016 at 1:51 PM, Yong Bakos wrote:\n> Appending a period to \"Everything up-to-date\" makes the output message\n> consistent with similar output in builtin/merge.c.\n>\n> Signed-off-by: Yong Bakos \n> ---\n> builtin/send-pack.c | 2 +-\n> transport.c | 2 +-\n> 2 files changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/builtin/send-pack.c b/builtin/send-pack.c\n> index 1ff5a67..67d9304 100644\n> --- a/builtin/send-pack.c\n> +++ b/builtin/send-pack.c\n\nWhile consistency is a good idea in general, I wonder how that applies here.\ngit-send-pack is a low level (i.e. plumbing) command.\n\n The interface (input, output, set of options and the semantics) to\n these low-level commands are meant to be a lot more stable than\n Porcelain level commands, because these commands are primarily for\n scripted use. The interface to Porcelain commands on the other hand are\n subject to change in order to improve the end user experience.\n\nSo if another porcelain exists and compares the output string\nexactly, this would be a regression for them. That is why I'd refrain\nfrom updating these strings\n\nHowever these two strings are only showing up in these 2 places, so\nmaybe instead\nwe'd want to see a test documenting existing behavior?\n\nThanks,\nStefan\n"},{"id":"287528","messageId":"20160525224733.GF13776@sigill.intra.peff.net","threadId":"42443","inReplyTo":"CAGZ79kayB59-U52oAw=13a2CAhJLsfmoD6JbAURbt0p8g8a8fg@mail.gmail.com","subject":"Re: [PATCH] transport, send-pack: append period to up-to-date message","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-05-25T22:47:34Z","receivedAt":"2016-05-25T22:47:34Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 24, 2016 at 02:21:00PM -0700, Stefan Beller wrote:\n\n> On Tue, May 24, 2016 at 1:51 PM, Yong Bakos wrote:\n> > Appending a period to \"Everything up-to-date\" makes the output message\n> > consistent with similar output in builtin/merge.c.\n> >\n> > Signed-off-by: Yong Bakos \n> > ---\n> > builtin/send-pack.c | 2 +-\n> > transport.c | 2 +-\n> > 2 files changed, 2 insertions(+), 2 deletions(-)\n> >\n> > diff --git a/builtin/send-pack.c b/builtin/send-pack.c\n> > index 1ff5a67..67d9304 100644\n> > --- a/builtin/send-pack.c\n> > +++ b/builtin/send-pack.c\n> \n> While consistency is a good idea in general, I wonder how that applies here.\n> git-send-pack is a low level (i.e. plumbing) command.\n> \n> The interface (input, output, set of options and the semantics) to\n> these low-level commands are meant to be a lot more stable than\n> Porcelain level commands, because these commands are primarily for\n> scripted use. The interface to Porcelain commands on the other hand are\n> subject to change in order to improve the end user experience.\n> \n> So if another porcelain exists and compares the output string\n> exactly, this would be a regression for them. That is why I'd refrain\n> from updating these strings\n\nI think messages to stderr are generally fair game for changing, even in\nplumbing. In many cases they are also translated (and I would argue that\nthese messages probably should be translated, too).\n\nThat being said, CodingGuidelines says:\n\n - Do not end error messages with a full stop.\n\nThis isn't an error message exactly, but I think it's in the same vein.\nI will note that we have not historically been consistent here, though\n(as evidenced by the noted message in git-merge).\n\n-Peff\n"},{"id":"287532","messageId":"xmqqy46xycg0.fsf@gitster.mtv.corp.google.com","threadId":"42443","inReplyTo":"20160525224733.GF13776@sigill.intra.peff.net","subject":"Re: [PATCH] transport, send-pack: append period to up-to-date message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-05-25T22:55:59Z","receivedAt":"2016-05-25T22:55:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think messages to stderr are generally fair game for changing, even in\n> plumbing. In many cases they are also translated (and I would argue that\n> these messages probably should be translated, too).\n\nI think I agree. My first reaction to this thread indeed was \"Why\nisn't this marked for translation?\"; as to the change proposed by\nthe patch itself, my reaction actually was \"Meh\" ;-)\n\n> That being said, CodingGuidelines says:\n>\n> - Do not end error messages with a full stop.\n\nThanks for pointing it out---I forgot about that one.\n\nI do not think there was a concrete reason why they should not end\nwith a full stop, other than \"be consistent with existing ones that\ndo not end with a full stop\", though.\n\n> This isn't an error message exactly, but I think it's in the same vein.\n> I will note that we have not historically been consistent here, though\n> (as evidenced by the noted message in git-merge).\n"},{"id":"287578","messageId":"AD23EFA5-FE44-4CE8-AD95-D95300E05B55@humanoriented.com","threadId":"42443","inReplyTo":"xmqqy46xycg0.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] transport, send-pack: append period to up-to-date message","fromName":"Yong Bakos","fromEmail":"junk@humanoriented.com","sentAt":"2016-05-26T14:16:11Z","receivedAt":"2016-05-26T14:16:11Z","isPatch":true,"sender":{"key":"junk@humanoriented.com","avatar":null},"body":"On May 25, 2016, at 5:55 PM, Junio C Hamano wrote:\n> \n> Jeff King writes:\n> \n>> I think messages to stderr are generally fair game for changing, even in\n>> plumbing. In many cases they are also translated (and I would argue that\n>> these messages probably should be translated, too).\n> \n> I think I agree. My first reaction to this thread indeed was \"Why\n> isn't this marked for translation?\"; as to the change proposed by\n> the patch itself, my reaction actually was \"Meh\" ;-)\n\nAw come one, Junio, you mean one \".\" doesn't excite you? :)\n\n> \n>> That being said, CodingGuidelines says:\n>> \n>> - Do not end error messages with a full stop.\n> \n> Thanks for pointing it out---I forgot about that one.\n> \n> I do not think there was a concrete reason why they should not end\n> with a full stop, other than \"be consistent with existing ones that\n> do not end with a full stop\", though.\n> \n>> This isn't an error message exactly, but I think it's in the same vein.\n>> I will note that we have not historically been consistent here, though\n>> (as evidenced by the noted message in git-merge).\n\nIndeed, most of the output during a pull/merge/push workflow breaks the\n\"don't end with a full stop\" guideline. I believe that this patch,\ndespite its candidacy for the \"most insignificant patch award,\" is a\nsane one.\n\nThanks for reviewing,\nyong\n"}]}