{"thread":{"id":"26907","subject":"Minor cosmetic defect in git-pack-objects output","startedAt":"2011-03-29T10:10:40Z","lastAt":"2011-03-29T20:48:34Z","messageCount":3,"participants":["Antonio Ospite","René Scharfe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"164557","messageId":"20110329121040.de22bd56.ospite@studenti.unina.it","threadId":"26907","inReplyTo":null,"subject":"Minor cosmetic defect in git-pack-objects output","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2011-03-29T10:10:40Z","receivedAt":"2011-03-29T10:10:40Z","isPatch":false,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"Hi,\n\nin some cases, on git-pack-objects failure, there is a small defect in\nthe output, see:\n\n# git gc --aggressive\nCounting objects: 1954118, done.\nDelta compression using up to 2 threads.\nwarning: suboptimal pack - out of memory02)   \nCompressing objects: 100% (1936802/1936802), done.\nWriting objects: 100% (1954118/1954118), done.\nTotal 1954118 (delta 1618716), reused 0 (delta 0)\n\nThe defect is here:\nwarning: suboptimal pack - out of memory02)\n                                        ^^^\nthe trailing chars are from the replaced line which was ending in\n1936802)\n\nAFAICS this is basically what is happening:\n#include \"git-compat-util.h\"\nfprintf(stderr, \"Compressing objects:  15% (296661/1936802)\\r\");\n                 warning(\"suboptimal pack - out of memory\");\n\nI can think to a dumb workaround for this particular path but maybe\nthere are other places when this can happen as well.\n\nAnyway it is not a big deal, but since I noticed it I wanted to report\nthat.\n\nRegards,\n   Antonio\n\n-- \nAntonio Ospite\nhttp://ao2.it\n\nPGP public key ID: 0x4553B001\n\nA: Because it messes up the order in which people normally read text.\n   See http://en.wikipedia.org/wiki/Posting_style\nQ: Why is top-posting such a bad thing?\n"},{"id":"164620","messageId":"4D923D59.3070301@lsrfire.ath.cx","threadId":"26907","inReplyTo":"20110329121040.de22bd56.ospite@studenti.unina.it","subject":"Re: Minor cosmetic defect in git-pack-objects output","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-03-29T20:13:13Z","receivedAt":"2011-03-29T20:13:13Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 29.03.2011 12:10, schrieb Antonio Ospite:\n> Hi,\n> \n> in some cases, on git-pack-objects failure, there is a small defect in\n> the output, see:\n> \n> # git gc --aggressive\n> Counting objects: 1954118, done.\n> Delta compression using up to 2 threads.\n> warning: suboptimal pack - out of memory02)\n> Compressing objects: 100% (1936802/1936802), done.\n> Writing objects: 100% (1954118/1954118), done.\n> Total 1954118 (delta 1618716), reused 0 (delta 0)\n> \n> The defect is here:\n> warning: suboptimal pack - out of memory02)\n>                                          ^^^\n> the trailing chars are from the replaced line which was ending in\n> 1936802)\n> \n> AFAICS this is basically what is happening:\n> #include \"git-compat-util.h\"\n> fprintf(stderr, \"Compressing objects:  15% (296661/1936802)\\r\");\n>                   warning(\"suboptimal pack - out of memory\");\n> \n> I can think to a dumb workaround for this particular path but maybe\n> there are other places when this can happen as well.\n\nThe following patch should avoid it by clearing the the rest of the\nline after warnings, error messages, usage notes etc. if stderr is a\nterminal.\n\nRené\n\n---\n usage.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/usage.c b/usage.c\nindex b5e67e3..36f1968 100644\n--- a/usage.c\n+++ b/usage.c\n@@ -9,7 +9,7 @@ void vreportf(const char *prefix, const char *err, va_list params)\n {\n \tchar msg[4096];\n \tvsnprintf(msg, sizeof(msg), err, params);\n-\tfprintf(stderr, \"%s%s\\n\", prefix, msg);\n+\tfprintf(stderr, \"%s%s%s\\n\", prefix, msg, isatty(2) ? \"\\033[K\" : \"\");\n }\n \n static NORETURN void usage_builtin(const char *err, va_list params)\n"},{"id":"164623","messageId":"20110329224834.62393f3c.ospite@studenti.unina.it","threadId":"26907","inReplyTo":"4D923D59.3070301@lsrfire.ath.cx","subject":"Re: Minor cosmetic defect in git-pack-objects output","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2011-03-29T20:48:34Z","receivedAt":"2011-03-29T20:48:34Z","isPatch":false,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"On Tue, 29 Mar 2011 22:13:13 +0200\nRené Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:\n\n> Am 29.03.2011 12:10, schrieb Antonio Ospite:\n> > Hi,\n> > \n> > in some cases, on git-pack-objects failure, there is a small defect in\n> > the output, see:\n> > \n> > # git gc --aggressive\n> > Counting objects: 1954118, done.\n> > Delta compression using up to 2 threads.\n> > warning: suboptimal pack - out of memory02)\n> > Compressing objects: 100% (1936802/1936802), done.\n> > Writing objects: 100% (1954118/1954118), done.\n> > Total 1954118 (delta 1618716), reused 0 (delta 0)\n> > \n> > The defect is here:\n> > warning: suboptimal pack - out of memory02)\n> >                                          ^^^\n> > the trailing chars are from the replaced line which was ending in\n> > 1936802)\n> > \n> > AFAICS this is basically what is happening:\n> > #include \"git-compat-util.h\"\n> > fprintf(stderr, \"Compressing objects:  15% (296661/1936802)\\r\");\n> >                   warning(\"suboptimal pack - out of memory\");\n> > \n> > I can think to a dumb workaround for this particular path but maybe\n> > there are other places when this can happen as well.\n> \n> The following patch should avoid it by clearing the the rest of the\n> line after warnings, error messages, usage notes etc. if stderr is a\n> terminal.\n>\n\nCool, this is working indeed on the terminal, I don't know if\nintroducing a CLEARLINE macro would look prettier.\n\nThanks René.\n\nRegards,\n   Antonio\n\n> René\n> \n> ---\n>  usage.c |    2 +-\n>  1 files changed, 1 insertions(+), 1 deletions(-)\n> \n> diff --git a/usage.c b/usage.c\n> index b5e67e3..36f1968 100644\n> --- a/usage.c\n> +++ b/usage.c\n> @@ -9,7 +9,7 @@ void vreportf(const char *prefix, const char *err, va_list params)\n>  {\n>  \tchar msg[4096];\n>  \tvsnprintf(msg, sizeof(msg), err, params);\n> -\tfprintf(stderr, \"%s%s\\n\", prefix, msg);\n> +\tfprintf(stderr, \"%s%s%s\\n\", prefix, msg, isatty(2) ? \"\\033[K\" : \"\");\n>  }\n>  \n>  static NORETURN void usage_builtin(const char *err, va_list params)\n> \n> \n\n\n-- \nAntonio Ospite\nhttp://ao2.it\n\nPGP public key ID: 0x4553B001\n\nA: Because it messes up the order in which people normally read text.\n   See http://en.wikipedia.org/wiki/Posting_style\nQ: Why is top-posting such a bad thing?\n"}]}