{"thread":{"id":"6931","subject":"[PATCH] Fixup no-progress for fetch & clone","startedAt":"2007-02-23T19:03:10Z","lastAt":"2007-02-24T17:56:29Z","messageCount":16,"participants":["Johannes Schindelin","Junio C Hamano","Nicolas Pitre","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"35344","messageId":"Pine.LNX.4.63.0702232002480.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6931","inReplyTo":null,"subject":"[PATCH] Fixup no-progress for fetch & clone","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-23T19:03:10Z","receivedAt":"2007-02-23T19:03:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nThe intent of the commit 'fetch & clone: do not output progress when\nnot on a tty' was to make fetching and cloning less chatty when\noutput was not redirected (such as in a cron job).\n\nHowever, there was a serious thinko in that commit. It assumed that\nthe client _and_ the server got this update at the same time. But\nthis is obviously not the case, and therefore upload-pack died on\nseeing the option \"--no-progress\".\n\nThis patch fixes that issue by making it a protocol option. So, until\nyour server is updated, you still see the progress, but once the\nserver has this patch, it will be quiet.\n\nA minor issue was also fixed: when cloning, the checkout did not\nheed no_progress.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tDo you want me to fold that back into the original patch?\n\n Documentation/git-upload-pack.txt | 5 +----\n fetch-pack.c | 10 +++-------\n git-clone.sh | 2 +-\n upload-pack.c | 10 ++++------\n 4 files changed, 9 insertions(+), 18 deletions(-)\n\ndiff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt\nindex c75c86e..fd65192 100644\n--- a/Documentation/git-upload-pack.txt\n+++ b/Documentation/git-upload-pack.txt\n@@ -8,7 +8,7 @@ git-upload-pack - Send objects packed back to git-fetch-pack\n \n SYNOPSIS\n --------\n-'git-upload-pack' [--strict] [--timeout=] [--no-progress] \n+'git-upload-pack' [--strict] [--timeout=] \n \n DESCRIPTION\n -----------\n@@ -30,9 +30,6 @@ OPTIONS\n \\--timeout=::\n \tInterrupt transfer after seconds of inactivity.\n \n-\\--no-progress::\n-\tDo not show the progress.\n-\n ::\n \tThe repository to sync from.\n \ndiff --git a/fetch-pack.c b/fetch-pack.c\nindex fc6b4e0..8428546 100644\n--- a/fetch-pack.c\n+++ b/fetch-pack.c\n@@ -174,12 +174,13 @@ static int find_common(int fd[2], unsigned char *result_sha1,\n \t\t}\n \n \t\tif (!fetching)\n-\t\t\tpacket_write(fd[1], \"want %s%s%s%s%s%s\\n\",\n+\t\t\tpacket_write(fd[1], \"want %s%s%s%s%s%s%s\\n\",\n \t\t\t\t sha1_to_hex(remote),\n \t\t\t\t (multi_ack ? \" multi_ack\" : \"\"),\n \t\t\t\t (use_sideband == 2 ? \" side-band-64k\" : \"\"),\n \t\t\t\t (use_sideband == 1 ? \" side-band\" : \"\"),\n \t\t\t\t (use_thin_pack ? \" thin-pack\" : \"\"),\n+\t\t\t\t (no_progress ? \" no-progress\" : \"\"),\n \t\t\t\t \" ofs-delta\");\n \t\telse\n \t\t\tpacket_write(fd[1], \"want %s\\n\", sha1_to_hex(remote));\n@@ -732,12 +733,7 @@ int main(int argc, char **argv)\n \t}\n \tif (!dest)\n \t\tusage(fetch_pack_usage);\n-\tif (no_progress) {\n-\t\tchar buf[256];\n-\t\tsnprintf(buf, sizeof(buf), \"%s --no-progress\", uploadpack);\n-\t\tpid = git_connect(fd, dest, buf);\n-\t} else\n-\t\tpid = git_connect(fd, dest, uploadpack);\n+\tpid = git_connect(fd, dest, uploadpack);\n \tif (pid < 0)\n \t\treturn 1;\n \tif (heads && nr_heads)\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 86890ea..de51983 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -395,7 +395,7 @@ then\n \n \tcase \"$no_checkout\" in\n \t'')\n-\t\ttest \"z$quiet\" = z && v=-v || v=\n+\t\ttest \"z$quiet\" = z -a \"z$no_progress\" = z && v=-v || v=\n \t\tgit-read-tree -m -u $v HEAD HEAD\n \tesac\n fi\ndiff --git a/upload-pack.c b/upload-pack.c\nindex d1be07f..d9907ca 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -10,7 +10,7 @@\n #include \"revision.h\"\n #include \"list-objects.h\"\n \n-static const char upload_pack_usage[] = \"git-upload-pack [--strict] [--timeout=nn] [--no-progress] \";\n+static const char upload_pack_usage[] = \"git-upload-pack [--strict] [--timeout=nn] \";\n \n /* bits #0..7 in revision.h, #8..10 in commit.c */\n #define THEY_HAVE\t(1u << 11)\n@@ -547,6 +547,8 @@ static void receive_needs(void)\n \t\t\tuse_sideband = LARGE_PACKET_MAX;\n \t\telse if (strstr(line+45, \"side-band\"))\n \t\t\tuse_sideband = DEFAULT_PACKET_MAX;\n+\t\tif (strstr(line+45, \"no-progress\"))\n+\t\t\tno_progress = 1;\n \n \t\t/* We have sent all our refs already, and the other end\n \t\t * should have chosen out of them; otherwise they are\n@@ -615,7 +617,7 @@ static void receive_needs(void)\n static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)\n {\n \tstatic const char *capabilities = \"multi_ack thin-pack side-band\"\n-\t\t\" side-band-64k ofs-delta shallow\";\n+\t\t\" side-band-64k ofs-delta shallow no-progress\";\n \tstruct object *o = parse_object(sha1);\n \n \tif (!o)\n@@ -670,10 +672,6 @@ int main(int argc, char **argv)\n \t\t\ttimeout = atoi(arg+10);\n \t\t\tcontinue;\n \t\t}\n-\t\tif (!strcmp(arg, \"--no-progress\")) {\n-\t\t\tno_progress = 1;\n-\t\t\tcontinue;\n-\t\t}\n \t\tif (!strcmp(arg, \"--\")) {\n \t\t\ti++;\n \t\t\tbreak;\n-- \n1.5.0.1.2248.g9f85a-dirty\n"},{"id":"35346","messageId":"7vfy8w3add.fsf@assigned-by-dhcp.cox.net","threadId":"6931","inReplyTo":"Pine.LNX.4.63.0702232002480.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-23T20:08:30Z","receivedAt":"2007-02-23T20:08:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Signed-off-by: Johannes Schindelin \n> ---\n>\n> \tDo you want me to fold that back into the original patch?\n\nThe js/fetch-progress topic is now part of 'next' so I won't\nrewind it. Fix-up on top as you did is preferable.\n"},{"id":"35358","messageId":"Pine.LNX.4.63.0702240217550.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6931","inReplyTo":"7vfy8w3add.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-24T01:19:55Z","receivedAt":"2007-02-24T01:19:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nSince most servers will not have a no-progress aware upload-pack, how \nabout this? (It is slightly ugly, but at least works...)\n\n-- snipsnap --\n[PATCH] git-fetch: add --no-progress, work around non-aware upload-pack\n\nThis adds the option \"--no-progress\" to git-fetch, and adds a\nworkaround for the case when the other side's upload-pack does\nnot support the \"no-progress\" extension: it skips the side-band\npackets ending in \"done\\r\".\n\nSigned-off-by: Johannes Schindelin \n\n---\n\n Documentation/fetch-options.txt | 5 +++++\n builtin-archive.c | 2 +-\n fetch-pack.c | 2 +-\n git-fetch.sh | 3 +++\n sideband.c | 6 +++++-\n sideband.h | 2 +-\n 6 files changed, 16 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex 5b4d184..3afb28e 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -22,6 +22,11 @@\n \tand stores them locally. This option disables this\n \tautomatic tag following.\n \n+\\--no-progress::\n+\tTell the other side not to show progress. If the other\n+\tside's upload-pack is new enough, it will actually\n+\theed that request.\n+\n -t, \\--tags::\n \tMost of the tags are fetched automatically as branch\n \theads are downloaded, but tags that do not point at\ndiff --git a/builtin-archive.c b/builtin-archive.c\nindex 8ea6cb1..3d3fd1b 100644\n--- a/builtin-archive.c\n+++ b/builtin-archive.c\n@@ -72,7 +72,7 @@ static int run_remote_archiver(const char *remote, int argc,\n \t\tdie(\"git-archive: expected a flush\");\n \n \t/* Now, start reading from fd[0] and spit it out to stdout */\n-\trv = recv_sideband(\"archive\", fd[0], 1, 2);\n+\trv = recv_sideband(\"archive\", fd[0], 1, 2, 0);\n \tclose(fd[0]);\n \tclose(fd[1]);\n \trv |= finish_connect(pid);\ndiff --git a/fetch-pack.c b/fetch-pack.c\nindex 06f4aec..fd38616 100644\n--- a/fetch-pack.c\n+++ b/fetch-pack.c\n@@ -482,7 +482,7 @@ static pid_t setup_sideband(int fd[2], int xd[2])\n \t\tclose(fd[0]);\n \t\tif (xd[0] != xd[1])\n \t\t\tclose(xd[1]);\n-\t\tif (recv_sideband(\"fetch-pack\", xd[0], fd[1], 2))\n+\t\tif (recv_sideband(\"fetch-pack\", xd[0], fd[1], 2, no_progress))\n \t\t\texit(1);\n \t\texit(0);\n \t}\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex 5ae0d28..e7a2be4 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -51,6 +51,9 @@ do\n \t-n|--n|--no|--no-|--no-t|--no-ta|--no-tag|--no-tags)\n \t\tno_tags=t\n \t\t;;\n+\t--no-progress)\n+\t\tno_progress=--no-progress\n+\t\t;;\n \t-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\\\n \t--update-he|--update-hea|--update-head|--update-head-|\\\n \t--update-head-o|--update-head-ok)\ndiff --git a/sideband.c b/sideband.c\nindex 277fa3c..6a1a181 100644\n--- a/sideband.c\n+++ b/sideband.c\n@@ -11,7 +11,8 @@\n * stream, aka \"verbose\"). A message over band #3 is a signal that\n * the remote died unexpectedly. A flush() concludes the stream.\n */\n-int recv_sideband(const char *me, int in_stream, int out, int err)\n+int recv_sideband(const char *me, int in_stream, int out, int err,\n+\t\tint no_progress)\n {\n \tchar buf[7 + LARGE_PACKET_MAX + 1];\n \tstrcpy(buf, \"remote:\");\n@@ -26,6 +27,9 @@ int recv_sideband(const char *me, int in_stream, int out, int err)\n \t\t\treturn SIDEBAND_PROTOCOL_ERROR;\n \t\t}\n \t\tband = buf[7] & 0xff;\n+\t\tif (no_progress && band != 3 && len > 7 + 5 &&\n+\t\t\t\t!prefixcmp(buf + 7 + len - 5, \"done\\r\"))\n+\t\t\tcontinue;\n \t\tlen--;\n \t\tswitch (band) {\n \t\tcase 3:\ndiff --git a/sideband.h b/sideband.h\nindex a84b691..99a0e96 100644\n--- a/sideband.h\n+++ b/sideband.h\n@@ -7,7 +7,7 @@\n #define DEFAULT_PACKET_MAX 1000\n #define LARGE_PACKET_MAX 65520\n \n-int recv_sideband(const char *me, int in_stream, int out, int err);\n+int recv_sideband(const char *me, int in_stream, int out, int err, int no_progress);\n ssize_t send_sideband(int fd, int band, const char *data, ssize_t sz, int packet_max);\n \n #endif\n"},{"id":"35361","messageId":"7vvehs1gxy.fsf@assigned-by-dhcp.cox.net","threadId":"6931","inReplyTo":"Pine.LNX.4.63.0702240217550.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-24T01:29:29Z","receivedAt":"2007-02-24T01:29:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Since most servers will not have a no-progress aware upload-pack, how \n> about this? (It is slightly ugly, but at least works...)\n\nPlease no.\n\nWhat's \"slight\" about this ugliness?\n\n> +\t\tif (no_progress && band != 3 && len > 7 + 5 &&\n> +\t\t\t\t!prefixcmp(buf + 7 + len - 5, \"done\\r\"))\n> +\t\t\tcontinue;\n"},{"id":"35369","messageId":"Pine.LNX.4.63.0702240245500.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6931","inReplyTo":"7vvehs1gxy.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-24T01:47:42Z","receivedAt":"2007-02-24T01:47:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Since most servers will not have a no-progress aware upload-pack, how \n> > about this? (It is slightly ugly, but at least works...)\n> \n> Please no.\n> \n> What's \"slight\" about this ugliness?\n> \n> > +\t\tif (no_progress && band != 3 && len > 7 + 5 &&\n> > +\t\t\t\t!prefixcmp(buf + 7 + len - 5, \"done\\r\"))\n> > +\t\t\tcontinue;\n\nThis is not the part I found ugly. In sideband, there is a lot of 7+len, \n8+len, buf+7.\n\nThe part I found ugly is having to touch builtin-archive.c\n\nBut I agree that we should not include that in mainline git. But at least \nthis patch is in the open for people who care deeply about no-progress \n_now_...\n\nCiao,\nDscho\n"},{"id":"35366","messageId":"alpine.LRH.0.82.0702232046300.29426@xanadu.home","threadId":"6931","inReplyTo":"Pine.LNX.4.63.0702240217550.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-24T01:48:12Z","receivedAt":"2007-02-24T01:48:12Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 24 Feb 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> Since most servers will not have a no-progress aware upload-pack, how \n> about this? (It is slightly ugly, but at least works...)\n\nJust slightly.\n\nWhy not simply filtering any string that ends in '\\r' ?\n\n\nNicolas\n"},{"id":"35375","messageId":"7vfy8w1evh.fsf@assigned-by-dhcp.cox.net","threadId":"6931","inReplyTo":"alpine.LRH.0.82.0702232046300.29426@xanadu.home","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-24T02:14:10Z","receivedAt":"2007-02-24T02:14:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Sat, 24 Feb 2007, Johannes Schindelin wrote:\n>\n>> Hi,\n>> \n>> Since most servers will not have a no-progress aware upload-pack, how \n>> about this? (It is slightly ugly, but at least works...)\n>\n> Just slightly.\n>\n> Why not simply filtering any string that ends in '\\r' ?\n\nYes. I think that I can live with.\n"},{"id":"35376","messageId":"Pine.LNX.4.63.0702240314250.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6931","inReplyTo":"alpine.LRH.0.82.0702232046300.29426@xanadu.home","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-24T02:15:22Z","receivedAt":"2007-02-24T02:15:22Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Feb 2007, Nicolas Pitre wrote:\n\n> On Sat, 24 Feb 2007, Johannes Schindelin wrote:\n> \n> > Since most servers will not have a no-progress aware upload-pack, how \n> > about this? (It is slightly ugly, but at least works...)\n> \n> Just slightly.\n> \n> Why not simply filtering any string that ends in '\\r' ?\n\nAs I mentioned in another mail, I find this issue not so ugly as that the \npatch touches a totally unrelated file, builtin-archive.c.\n\nCiao,\nDscho\n"},{"id":"35379","messageId":"alpine.LRH.0.82.0702232123110.29426@xanadu.home","threadId":"6931","inReplyTo":"Pine.LNX.4.63.0702240314250.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-24T02:28:39Z","receivedAt":"2007-02-24T02:28:39Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 24 Feb 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Fri, 23 Feb 2007, Nicolas Pitre wrote:\n> \n> > On Sat, 24 Feb 2007, Johannes Schindelin wrote:\n> > \n> > > Since most servers will not have a no-progress aware upload-pack, how \n> > > about this? (It is slightly ugly, but at least works...)\n> > \n> > Just slightly.\n> > \n> > Why not simply filtering any string that ends in '\\r' ?\n> \n> As I mentioned in another mail, I find this issue not so ugly as that the \n> patch touches a totally unrelated file, builtin-archive.c.\n\nActually that is not the part that bothered me at all.\n\nWhat really bothered me is the implicit knowledge added to the sideband \nstuff about \"done\\r\".\n\nAnd since all progress strings ar likely to end in '\\r' for easy \nredrawing then I think your patch would be so much cleaner if you'd only \ndiscard any remote string that ends in \\r, or only contains a single \\n. \nAfter all those are the strings you don't want to see in your log files.\n\nAnd I would do that and _only_ that to supress progress. No messing \naround with protocol extensions. Just filter out the unwanted messages \nlocally and be happy.\n\n\nNicolas\n"},{"id":"35380","messageId":"Pine.LNX.4.63.0702240336130.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6931","inReplyTo":"alpine.LRH.0.82.0702232123110.29426@xanadu.home","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-24T02:37:23Z","receivedAt":"2007-02-24T02:37:23Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Feb 2007, Nicolas Pitre wrote:\n\n> And I would do that and _only_ that to supress progress. No messing \n> around with protocol extensions. Just filter out the unwanted messages \n> locally and be happy.\n\nThis is easier, but I'd feel dirty about it. I mean, you set up a signal \nevery so often, have a side band, demultiplex the side band, and for what? \nTo just ignore it?\n\nCiao,\nDscho\n"},{"id":"35381","messageId":"alpine.LRH.0.82.0702232141040.29426@xanadu.home","threadId":"6931","inReplyTo":"Pine.LNX.4.63.0702240336130.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-24T02:47:46Z","receivedAt":"2007-02-24T02:47:46Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 24 Feb 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Fri, 23 Feb 2007, Nicolas Pitre wrote:\n> \n> > And I would do that and _only_ that to supress progress. No messing \n> > around with protocol extensions. Just filter out the unwanted messages \n> > locally and be happy.\n> \n> This is easier, but I'd feel dirty about it. I mean, you set up a signal \n> every so often, have a side band, demultiplex the side band, and for what? \n> To just ignore it?\n\nYes sir. But of course this isn't the default. \n\nAnd it isn't even the common case either. So I think a bit of cheating \nto keep the common case simple isn't that bad.\n\nAnd it is not like if the whole thing was thrown away. For example I \nthink messages like\n\n\tremote: Writing 1234 objects.\n\nare good messages to have in a log file even when progress display is \nfiltered out. So the sideband demultiplexing is useful in that case as \nwell.\n\n\nNicolas\n"},{"id":"35382","messageId":"7vbqjk17a8.fsf@assigned-by-dhcp.cox.net","threadId":"6931","inReplyTo":"alpine.LRH.0.82.0702232141040.29426@xanadu.home","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-24T04:58:07Z","receivedAt":"2007-02-24T04:58:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> And it is not like if the whole thing was thrown away. For example I \n> think messages like\n>\n> \tremote: Writing 1234 objects.\n>\n> are good messages to have in a log file even when progress display is \n> filtered out. So the sideband demultiplexing is useful in that case as \n> well.\n\nIn that case, maybe we should define a separate sideband for\nprogress display? Currently #1 (payload) and #3 (emergency\nexit) are distinct but #2 corresponds to stderr which has info\nmessages and progress noise all mixed up.\n"},{"id":"35383","messageId":"alpine.LRH.0.82.0702240005270.29426@xanadu.home","threadId":"6931","inReplyTo":"7vbqjk17a8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-24T05:14:55Z","receivedAt":"2007-02-24T05:14:55Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 23 Feb 2007, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > And it is not like if the whole thing was thrown away. For example I \n> > think messages like\n> >\n> > \tremote: Writing 1234 objects.\n> >\n> > are good messages to have in a log file even when progress display is \n> > filtered out. So the sideband demultiplexing is useful in that case as \n> > well.\n> \n> In that case, maybe we should define a separate sideband for\n> progress display? Currently #1 (payload) and #3 (emergency\n> exit) are distinct but #2 corresponds to stderr which has info\n> messages and progress noise all mixed up.\n\nAnd how would the remote end distinguish how to split the info from the \nprogress noise? Teaching pack-object about another file descriptor?\nAnd what happen if pack-object is run locally in that case?\n\nHow does that solve the issue with servers (currently all of them) that \ndon't know about the new sideband?\n\nI think life might just be so much simpler if we just decide right now \nthat progress noise is defined as a string ending witha '\\r', and that \nwe just toss it locally when we don't want progress noise. As a bonus \nthis is even fully backward compatible with all existing servers.\n\n\nNicolas\n"},{"id":"35385","messageId":"7v7iu80y6i.fsf@assigned-by-dhcp.cox.net","threadId":"6931","inReplyTo":"alpine.LRH.0.82.0702240005270.29426@xanadu.home","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-24T08:14:45Z","receivedAt":"2007-02-24T08:14:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> And how would the remote end distinguish how to split the info from the \n> progress noise? Teaching pack-object about another file descriptor?\n> And what happen if pack-object is run locally in that case?\n\nThat's true, and your convention to classify line with \"\\r\"\nnoise and others as info is as good as anything, and does not\nbreak any existing system, so it is very good one.\n\n> How does that solve the issue with servers (currently all of them) that \n> don't know about the new sideband?\n\nI actually happen to consider that a non problem.\n\nIt is true that you can only prepare the client and server side\nby 1.5.1, and new clients talking to 1.5.0 or older servers\nwould not be able to squelch the noise. But that is _not_ a new\nproblem anyway, and given time the server side will eventually\nbe updated to 1.5.1 or later. If anything else, it would give\nincentive to people to upgrade their servers to 1.5.1 ;-)\n"},{"id":"35397","messageId":"alpine.LRH.0.82.0702240922250.29426@xanadu.home","threadId":"6931","inReplyTo":"7v7iu80y6i.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-24T14:27:57Z","receivedAt":"2007-02-24T14:27:57Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 24 Feb 2007, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > How does that solve the issue with servers (currently all of them) that \n> > don't know about the new sideband?\n> \n> I actually happen to consider that a non problem.\n> \n> It is true that you can only prepare the client and server side\n> by 1.5.1, and new clients talking to 1.5.0 or older servers\n> would not be able to squelch the noise. But that is _not_ a new\n> problem anyway, and given time the server side will eventually\n> be updated to 1.5.1 or later. If anything else, it would give\n> incentive to people to upgrade their servers to 1.5.1 ;-)\n\nWell... for such a special case feature I doubt this might be such a \ngreat insentive. And since locally filtering on '\\r' is so simple I \nwonder what the complexity of the alternative solution really buys us.\n\n\nNicolas\n\n\n\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n\n\nNicolas\n"},{"id":"35401","messageId":"erpu4b$daa$1@sea.gmane.org","threadId":"6931","inReplyTo":"alpine.LRH.0.82.0702240922250.29426@xanadu.home","subject":"Re: [PATCH] Fixup no-progress for fetch & clone","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-24T17:56:29Z","receivedAt":"2007-02-24T17:56:29Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n\n> On Sat, 24 Feb 2007, Junio C Hamano wrote:\n> \n>> Nicolas Pitre writes:\n>> \n>>> How does that solve the issue with servers (currently all of them) that \n>>> don't know about the new sideband?\n>> \n>> I actually happen to consider that a non problem.\n>> \n>> It is true that you can only prepare the client and server side\n>> by 1.5.1, and new clients talking to 1.5.0 or older servers\n>> would not be able to squelch the noise. But that is _not_ a new\n>> problem anyway, and given time the server side will eventually\n>> be updated to 1.5.1 or later. If anything else, it would give\n>> incentive to people to upgrade their servers to 1.5.1 ;-)\n> \n> Well... for such a special case feature I doubt this might be such a \n> great insentive. And since locally filtering on '\\r' is so simple I \n> wonder what the complexity of the alternative solution really buys us.\n\nSlighly less bandwidth used (we don't send progress report)?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}