{"thread":{"id":"23596","subject":"Bugreport: Git responds with stderr instead of stdout","startedAt":"2010-04-25T18:06:07Z","lastAt":"2010-06-26T16:50:30Z","messageCount":19,"participants":["Jack Desert","Jacob Helwig","Ævar Arnfjörð Bjarmason","Jeff King","Junio C Hamano","Tay Ray Chuan"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140351","messageId":"20100425130607.2c92740f@pennie-farthing","threadId":"23596","inReplyTo":null,"subject":"Bugreport: Git responds with stderr instead of stdout","fromName":"Jack Desert","fromEmail":"jackdesert556@gmail.com","sentAt":"2010-04-25T18:06:07Z","receivedAt":"2010-04-25T18:06:07Z","isPatch":false,"sender":{"key":"jackdesert556@gmail.com","avatar":"https://gravatar.com/avatar/7301a1f907236ca587d9d48f34c58498d842b3f6ef4dfcbb10edb3c1818e31c8?d=mp&s=160"},"body":"I think I found a bug in Git. When I run the command \n\n  git checkout -b new_branch\n\nGit does exactly what I've asked, except that Git's response:\n  \n  Switched to a new branch 'new_branch'\n\ncomes through the stderr pipe instead of through the stdout pipe. Where do I file a bug report for this? \n\nI am using Git 1.6.3.3, Ubuntu 9.10\n\n-Jack\n\n\n-- \n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nJack Desert     --    Writer, Entrepeneur\nAuthor and Spokesman: www.LetsEATalready.com\nSoftware Developer:   http://GrooveTask.org\nEmail: JackDesert556@gmail.com\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n"},{"id":"140353","messageId":"v2m8c9a061004251110paf7ba4e5r1997bc6262afcb1d@mail.gmail.com","threadId":"23596","inReplyTo":"20100425130607.2c92740f@pennie-farthing","subject":"Re: Bugreport: Git responds with stderr instead of stdout","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-04-25T18:10:47Z","receivedAt":"2010-04-25T18:10:47Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Sun, Apr 25, 2010 at 11:06, Jack Desert <jackdesert556@gmail.com> wrote:\n> I think I found a bug in Git. When I run the command\n>\n>  git checkout -b new_branch\n>\n> Git does exactly what I've asked, except that Git's response:\n>\n>  Switched to a new branch 'new_branch'\n>\n> comes through the stderr pipe instead of through the stdout pipe. Where do I file a bug report for this?\n>\n> I am using Git 1.6.3.3, Ubuntu 9.10\n>\n> -Jack\n>\n>\n\nI can't really say if it's actually a bug, or not, but as to your\nquestion about where to file a bug report: You just did.  This mailing\nlist is the correct place.\n"},{"id":"140354","messageId":"y2g51dd1af81004251124zc4da759dka2ceebe1d9735fd7@mail.gmail.com","threadId":"23596","inReplyTo":"v2m8c9a061004251110paf7ba4e5r1997bc6262afcb1d@mail.gmail.com","subject":"Re: Bugreport: Git responds with stderr instead of stdout","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-25T18:24:43Z","receivedAt":"2010-04-25T18:24:43Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Apr 25, 2010 at 18:10, Jacob Helwig <jacob.helwig@gmail.com> wrote:\n> I can't really say if it's actually a bug, or not, but as to your\n> question about where to file a bug report: You just did.  This mailing\n> list is the correct place.\n\nI've had some issues scripting `git fetch` because on error it'll\nprint to stdout and not stderr.\n\nAre there some general guidelines for git's utilities that they follow\nin this regard or does each tool just do its own thing?\n"},{"id":"140355","messageId":"20100425133453.3da77af9@pennie-farthing","threadId":"23596","inReplyTo":"v2m8c9a061004251110paf7ba4e5r1997bc6262afcb1d@mail.gmail.com","subject":"Re: Bugreport: Git responds with stderr instead of stdout","fromName":"Jack Desert","fromEmail":"jackdesert556@gmail.com","sentAt":"2010-04-25T18:34:53Z","receivedAt":"2010-04-25T18:34:53Z","isPatch":false,"sender":{"key":"jackdesert556@gmail.com","avatar":"https://gravatar.com/avatar/7301a1f907236ca587d9d48f34c58498d842b3f6ef4dfcbb10edb3c1818e31c8?d=mp&s=160"},"body":"El Sun, 25 Apr 2010 11:10:47 -0700\nJacob Helwig <jacob.helwig@gmail.com> escribió:\n> On Sun, Apr 25, 2010 at 11:06, Jack Desert <jackdesert556@gmail.com> wrote:\n> > I think I found a bug in Git. When I run the command\n> >\n> >  git checkout -b new_branch\n> >\n> > Git does exactly what I've asked, except that Git's response:\n> >\n> >  Switched to a new branch 'new_branch'\n> >\n> > comes through the stderr pipe instead of through the stdout pipe. Where do I file a bug report for this?\n> >\n> > I am using Git 1.6.3.3, Ubuntu 9.10\n> >\n> > -Jack\n> >\n> >\n> \n> I can't really say if it's actually a bug, or not, but as to your\n> question about where to file a bug report: You just did.  This mailing\n> list is the correct place.\n\nI just finished testing with the latest development version and it has the same issue that 1.6.3.3 has in this regard. \n\n\n-- \n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nJack Desert     --    Writer, Entrepeneur\nAuthor and Spokesman: www.LetsEATalready.com\nSoftware Developer:   http://GrooveTask.org\nEmail: JackDesert556@gmail.com\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n"},{"id":"140358","messageId":"20100425192207.GA14736@coredump.intra.peff.net","threadId":"23596","inReplyTo":"y2g51dd1af81004251124zc4da759dka2ceebe1d9735fd7@mail.gmail.com","subject":"Re: Bugreport: Git responds with stderr instead of stdout","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-25T19:22:07Z","receivedAt":"2010-04-25T19:22:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Apr 25, 2010 at 06:24:43PM +0000, Ævar Arnfjörð Bjarmason wrote:\n\n> On Sun, Apr 25, 2010 at 18:10, Jacob Helwig <jacob.helwig@gmail.com> wrote:\n> > I can't really say if it's actually a bug, or not, but as to your\n> > question about where to file a bug report: You just did.  This mailing\n> > list is the correct place.\n> \n> I've had some issues scripting `git fetch` because on error it'll\n> print to stdout and not stderr.\n\nErrors should go to stderr, so I imagine patches would be welcome. Which\nmessages went to stdout?\n\n> Are there some general guidelines for git's utilities that they follow\n> in this regard or does each tool just do its own thing?\n\nIn practice, each tool does its own thing because they evolved\ndifferently and from different authors. I think we are slowly converging\non similar behavior, though, as people fix warts.  As to exactly what\nthat behavior is, I don't know that anybody has ever enumerated it\nexactly. Verbose status and progress reports, especially human readable\nones, should probably always go to stderr.\n\nThe \"Switched to a new branch\" message that started this thread is\ncorrect to go to stderr.  If you want to silence the message but keep\nstderr open for actual errors, the right way is to use \"-q\".\n\nI tend to think the only thing that should go to stdout is the \"main\"\noutput of a command. For something like \"ls-files\", that is obviously\nthe list of files. For something like \"checkout\", which is about\nchanging the repository and not about querying it, I think there is\nprobably nothing that makes sense on stdout.\n\n-Peff\n"},{"id":"140359","messageId":"m2h51dd1af81004251232ue621ca42r7168429f45d20461@mail.gmail.com","threadId":"23596","inReplyTo":"20100425192207.GA14736@coredump.intra.peff.net","subject":"Re: Bugreport: Git responds with stderr instead of stdout","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-25T19:32:00Z","receivedAt":"2010-04-25T19:32:00Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Apr 25, 2010 at 19:22, Jeff King <peff@peff.net> wrote:\n> On Sun, Apr 25, 2010 at 06:24:43PM +0000, Ævar Arnfjörð Bjarmason wrote:\n>\n>> On Sun, Apr 25, 2010 at 18:10, Jacob Helwig <jacob.helwig@gmail.com> wrote:\n>> > I can't really say if it's actually a bug, or not, but as to your\n>> > question about where to file a bug report: You just did.  This mailing\n>> > list is the correct place.\n>>\n>> I've had some issues scripting `git fetch` because on error it'll\n>> print to stdout and not stderr.\n>\n> Errors should go to stderr, so I imagine patches would be welcome. Which\n> messages went to stdout?\n\nI can't recall exactly now. Looking at fetch.c I can't see anything\nobvious, I'll report anything if I spot it in the future.\n"},{"id":"140360","messageId":"20100425193258.GA16171@coredump.intra.peff.net","threadId":"23596","inReplyTo":"m2h51dd1af81004251232ue621ca42r7168429f45d20461@mail.gmail.com","subject":"Re: Bugreport: Git responds with stderr instead of stdout","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-25T19:32:58Z","receivedAt":"2010-04-25T19:32:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Apr 25, 2010 at 07:32:00PM +0000, Ævar Arnfjörð Bjarmason wrote:\n\n> >> I've had some issues scripting `git fetch` because on error it'll\n> >> print to stdout and not stderr.\n> >\n> > Errors should go to stderr, so I imagine patches would be welcome. Which\n> > messages went to stdout?\n> \n> I can't recall exactly now. Looking at fetch.c I can't see anything\n> obvious, I'll report anything if I spot it in the future.\n\nThanks. As I mentioned, we've been fixing little things like this as\ntime goes on, so it may well have been fixed already.\n\n-Peff\n"},{"id":"143583","messageId":"AANLkTingtgeWuTrocesTIhTPsVz4dfU8CbwZF1TEl6AI@mail.gmail.com","threadId":"23596","inReplyTo":"20100425193258.GA16171@coredump.intra.peff.net","subject":"Re: Bugreport: Git responds with stderr instead of stdout","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-06-12T16:52:34Z","receivedAt":"2010-06-12T16:52:34Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Apr 25, 2010 at 19:32, Jeff King <peff@peff.net> wrote:\n> On Sun, Apr 25, 2010 at 07:32:00PM +0000, Ævar Arnfjörð Bjarmason wrote:\n>\n>> >> I've had some issues scripting `git fetch` because on error it'll\n>> >> print to stdout and not stderr.\n>> >\n>> > Errors should go to stderr, so I imagine patches would be welcome. Which\n>> > messages went to stdout?\n>>\n>> I can't recall exactly now. Looking at fetch.c I can't see anything\n>> obvious, I'll report anything if I spot it in the future.\n>\n> Thanks. As I mentioned, we've been fixing little things like this as\n> time goes on, so it may well have been fixed already.\n\nActually here's an example with Git 1.7.1:\n\n    # time /etc/github-backup/github-backup\n    remote: Counting objects: 76, done.\n    remote: Compressing objects: 100% (43/43), done.\n    remote: Total 47 (delta 26), reused 18 (delta 4)\n    Unpacking objects: 100% (47/47), done.\n    From github.com:avar/linode-etc\n       75a27cf..09d5ff7  master     -> origin/master\n    From github.com:avar/svn-dump-fast-export\n     * [new branch]      gh-pages   -> origin/gh-pages\n     * [new branch]      git-merge  -> origin/git-merge\n     * [new branch]      master     -> origin/master\n     * [new branch]      rollout    -> origin/rollout\n\nThe script I'm running is github-backup\n(http://github.com/avar/github-backup) which just outputs `git fetch`\noutput as-is.\n\nLooking at the source the problematic code is in builtin/fetch.c's\nupdate_local_ref. That function takes a char *display which it writes\nto things that are both errors and just status messages:\n\nError:\n\n\t\tsprintf(display, \"! %-*s %-*s -> %s  (can't fetch in current branch)\",\n\t\t\tTRANSPORT_SUMMARY_WIDTH, \"[rejected]\", REFCOL_WIDTH, remote,\n\t\t\tpretty_ref);\n\nJust a status message (in my case):\n\n\t\telse {\n\t\t\tmsg = \"storing head\";\n\t\t\twhat = \"[new branch]\";\n\t\t}\n\n\t\tr = s_update_ref(msg, ref, 0);\n\t\tsprintf(display, \"%c %-*s %-*s -> %s%s\", r ? '!' : '*',\n\t\t\tTRANSPORT_SUMMARY_WIDTH, what, REFCOL_WIDTH, remote, pretty_ref,\n\t\t\tr ? \"  (unable to update local ref)\" : \"\");\n\nThat function is then called as:\n\n\t\tif (ref) {\n\t\t\trc |= update_local_ref(ref, what, note);\n\t\t\tfree(ref);\n\t\t} else\n\t\t\tsprintf(note, \"* %-*s %-*s -> FETCH_HEAD\",\n\t\t\t\tTRANSPORT_SUMMARY_WIDTH, *kind ? kind : \"branch\",\n\t\t\t\t REFCOL_WIDTH, *what ? what : \"HEAD\");\n\t\tif (*note) {\n\t\t\tif (verbosity >= 0 && !shown_url) {\n\t\t\t\tfprintf(stderr, \"From %.*s\\n\",\n\t\t\t\t\t\turl_len, url);\n\t\t\t\tshown_url = 1;\n\t\t\t}\n\t\t\tif (verbosity >= 0)\n\t\t\t\tfprintf(stderr, \" %s\\n\", note);\n\t\t}\n\nShouldn't that fprintf() be called as:\n\n    fprintf((rc ? stderr : stdout), ...)\n\n?\n"},{"id":"144214","messageId":"1277418881-11286-1-git-send-email-avarab@gmail.com","threadId":"23596","inReplyTo":"AANLkTingtgeWuTrocesTIhTPsVz4dfU8CbwZF1TEl6AI@mail.gmail.com","subject":"[PATCH] fetch: don't output non-errors on stderr","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-06-24T22:34:41Z","receivedAt":"2010-06-24T22:34:41Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Change git-fetch to only print to stderr if it has encountered an\nerror.\n\nA normal branch update (like \"* branch HEAD -> FETCH_HEAD\") is no\nlonger output to stderr but on stdout. Genuine errors (like\n\"[rejected]\" messages) still go to stderr.\n\nWith this change I can run a cron script I've been developing\n(http://github.com/avar/github-backup) without redirecting stderr to\n/dev/null.\n\nBefore the change error messages were drowned out by git-fetch's\nnon-error update notices, which didn't need my attention.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n\nOn Sat, Jun 12, 2010 at 16:52, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n\n> Shouldn't that fprintf() be called as:\n>\n>    fprintf((rc ? stderr : stdout), ...)\n\nTo answer my own question: Yes it should. This patch fixes git-fetch\nso that it doesn't taint stderr with non-error messages.\n\nThe small changes to the test suite that this requires is a testiment\nto how bad our test coverage is in this area. As far as I can see the\nerror messages that update_local_ref can emit aren't being tested\nfor. Fixing that is outside the scope of this patch, however.\n\n builtin/fetch.c         |    5 +++--\n t/t5521-pull-options.sh |   12 ++++++------\n 2 files changed, 9 insertions(+), 8 deletions(-)\n\ndiff --git a/builtin/fetch.c b/builtin/fetch.c\nindex 5cb369c..116b322 100644\n--- a/builtin/fetch.c\n+++ b/builtin/fetch.c\n@@ -397,13 +397,14 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,\n \t\t\t\tTRANSPORT_SUMMARY_WIDTH, *kind ? kind : \"branch\",\n \t\t\t\t REFCOL_WIDTH, *what ? what : \"HEAD\");\n \t\tif (*note) {\n+\t\t\tFILE *fout = rc ? stderr : stdout;\n \t\t\tif (verbosity >= 0 && !shown_url) {\n-\t\t\t\tfprintf(stderr, \"From %.*s\\n\",\n+\t\t\t\tfprintf(fout, \"From %.*s\\n\",\n \t\t\t\t\t\turl_len, url);\n \t\t\t\tshown_url = 1;\n \t\t\t}\n \t\t\tif (verbosity >= 0)\n-\t\t\t\tfprintf(stderr, \" %s\\n\", note);\n+\t\t\t\tfprintf(fout, \" %s\\n\", note);\n \t\t}\n \t}\n \tfree(url);\ndiff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh\nindex 1b06691..7ec36e7 100755\n--- a/t/t5521-pull-options.sh\n+++ b/t/t5521-pull-options.sh\n@@ -23,16 +23,16 @@ test_expect_success 'git pull' '\n \tmkdir cloned &&\n \t(cd cloned && git init &&\n \tgit pull \"../parent\" >out 2>err &&\n-\ttest -s err &&\n-\ttest ! -s out)\n+\ttest ! -s err &&\n+\ttest -s out)\n '\n \n test_expect_success 'git pull -v' '\n \tmkdir clonedv &&\n \t(cd clonedv && git init &&\n \tgit pull -v \"../parent\" >out 2>err &&\n-\ttest -s err &&\n-\ttest ! -s out)\n+\ttest ! -s err &&\n+\ttest -s out)\n '\n \n test_expect_success 'git pull -v -q' '\n@@ -47,8 +47,8 @@ test_expect_success 'git pull -q -v' '\n \tmkdir clonedqv &&\n \t(cd clonedqv && git init &&\n \tgit pull -q -v \"../parent\" >out 2>err &&\n-\ttest ! -s out &&\n-\ttest -s err)\n+\ttest ! -s err &&\n+\ttest -s out)\n '\n \n test_expect_success 'git pull --force' '\n-- \n1.7.1.251.g92a7\n"},{"id":"144240","messageId":"1277472641-18148-1-git-send-email-avarab@gmail.com","threadId":"23596","inReplyTo":"1277418881-11286-1-git-send-email-avarab@gmail.com","subject":"[PATCH v2] fetch: don't output non-errors on stderr","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-06-25T13:30:41Z","receivedAt":"2010-06-25T13:30:41Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Change git-fetch to only print to stderr if it has encountered an\nerror. A normal branch update (like \"* branch HEAD -> FETCH_HEAD\") is\nno longer output to stderr but on stdout. Genuine errors (like\n\"[rejected]\" messages) still go to stderr.\n\nWith this change I can run a cron script I've been developing\n(http://github.com/avar/github-backup) without redirecting stderr to\n/dev/null.\n\nBefore the change error messages were drowned out by git-fetch's\nnon-error update notices, which didn't need my attention.\n\nThe changes in t/t5521-pull-options.sh invert the previously tested\nfor behavior of checking if normal messages are output on stderr. The\nchanges in t/t5510-fetch.sh however contain no behavioral changes,\njust assertions that will break if git fetch's behavior is changed\nagain.\n\nThere still aren't tests for some of the errors output by\nbuiltin/fetch.c's update_local_ref function.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n\nOn Thu, Jun 24, 2010 at 22:34, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n\n> The small changes to the test suite that this requires is a testiment\n> to how bad our test coverage is in this area. As far as I can see the\n> error messages that update_local_ref can emit aren't being tested\n> for. Fixing that is outside the scope of this patch, however.\n\nHere's an updated patch that has a some of those supposedly out of\nscope tests. The new tests have the same behavior, but will start\nbreaking if this behavior is changed again.\n\n builtin/fetch.c         |    5 ++-\n t/t5510-fetch.sh        |   57 +++++++++++++++++++++++++++++++++-------------\n t/t5521-pull-options.sh |   12 +++++-----\n 3 files changed, 50 insertions(+), 24 deletions(-)\n\ndiff --git a/builtin/fetch.c b/builtin/fetch.c\nindex 5cb369c..116b322 100644\n--- a/builtin/fetch.c\n+++ b/builtin/fetch.c\n@@ -397,13 +397,14 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,\n \t\t\t\tTRANSPORT_SUMMARY_WIDTH, *kind ? kind : \"branch\",\n \t\t\t\t REFCOL_WIDTH, *what ? what : \"HEAD\");\n \t\tif (*note) {\n+\t\t\tFILE *fout = rc ? stderr : stdout;\n \t\t\tif (verbosity >= 0 && !shown_url) {\n-\t\t\t\tfprintf(stderr, \"From %.*s\\n\",\n+\t\t\t\tfprintf(fout, \"From %.*s\\n\",\n \t\t\t\t\t\turl_len, url);\n \t\t\t\tshown_url = 1;\n \t\t\t}\n \t\t\tif (verbosity >= 0)\n-\t\t\t\tfprintf(stderr, \" %s\\n\", note);\n+\t\t\t\tfprintf(fout, \" %s\\n\", note);\n \t\t}\n \t}\n \tfree(url);\ndiff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh\nindex 4eb10f6..808b256 100755\n--- a/t/t5510-fetch.sh\n+++ b/t/t5510-fetch.sh\n@@ -51,7 +51,9 @@ test_expect_success \"fetch test\" '\n \techo >file updated by origin &&\n \tgit commit -a -m \"updated by origin\" &&\n \tcd two &&\n-\tgit fetch &&\n+\tgit fetch >out 2>err &&\n+\ttest ! -s err &&\n+\ttest -s out &&\n \ttest -f .git/refs/heads/one &&\n \tmine=`git rev-parse refs/heads/one` &&\n \this=`cd ../one && git rev-parse refs/heads/master` &&\n@@ -61,7 +63,9 @@ test_expect_success \"fetch test\" '\n test_expect_success \"fetch test for-merge\" '\n \tcd \"$D\" &&\n \tcd three &&\n-\tgit fetch &&\n+\tgit fetch >out 2>err &&\n+\ttest ! -s err &&\n+\ttest -s out &&\n \ttest -f .git/refs/heads/two &&\n \ttest -f .git/refs/heads/one &&\n \tmaster_in_two=`cd ../two && git rev-parse master` &&\n@@ -81,7 +85,9 @@ test_expect_success 'fetch tags when there is no tags' '\n     cd notags &&\n     git init &&\n \n-    git fetch -t ..\n+    git fetch -t .. >out 2>err &&\n+    test ! -s err &&\n+    test ! -s out\n \n '\n \n@@ -95,7 +101,10 @@ test_expect_success 'fetch following tags' '\n \tcd four &&\n \tgit init &&\n \n-\tgit fetch .. :track &&\n+\tgit fetch .. :track >out 2>err &&\n+\ttest ! -s err &&\n+\ttest -s out &&\n+\n \tgit show-ref --verify refs/tags/anno &&\n \tgit show-ref --verify refs/tags/light\n \n@@ -109,8 +118,9 @@ test_expect_success 'fetch must not resolve short tag name' '\n \tcd five &&\n \tgit init &&\n \n-\ttest_must_fail git fetch .. anno:five\n-\n+\t! git fetch .. anno:five >out 2>err &&\n+\ttest -s err &&\n+\ttest ! -s out\n '\n \n test_expect_success 'fetch must not resolve short remote name' '\n@@ -122,7 +132,9 @@ test_expect_success 'fetch must not resolve short remote name' '\n \tcd six &&\n \tgit init &&\n \n-\ttest_must_fail git fetch .. six:six\n+\t! git fetch .. six:six >out 2>err &&\n+\ttest -s err &&\n+\ttest ! -s out\n \n '\n \n@@ -148,7 +160,9 @@ test_expect_success 'create bundle 2' '\n test_expect_success 'unbundle 1' '\n \tcd \"$D/bundle\" &&\n \tgit checkout -b some-branch &&\n-\ttest_must_fail git fetch \"$D/bundle1\" master:master\n+\t! git fetch \"$D/bundle1\" master:master >out 2>err &&\n+\ttest -s err &&\n+\ttest ! -s out\n '\n \n \n@@ -167,7 +181,9 @@ test_expect_success 'bundle 1 has only 3 files ' '\n \n test_expect_success 'unbundle 2' '\n \tcd \"$D/bundle\" &&\n-\tgit fetch ../bundle2 master:master &&\n+\tgit fetch ../bundle2 master:master >out 2>err &&\n+\ttest ! -s err &&\n+\ttest -s out &&\n \ttest \"tip\" = \"$(git log -1 --pretty=oneline master | cut -b42-)\"\n '\n \n@@ -203,7 +219,9 @@ test_expect_success 'fetch via rsync' '\n \tmkdir rsynced &&\n \t(cd rsynced &&\n \t git init --bare &&\n-\t git fetch \"rsync:$(pwd)/../.git\" master:refs/heads/master &&\n+\t git fetch \"rsync:$(pwd)/../.git\" master:refs/heads/master >out 2>err &&\n+\t test ! -s err &&\n+\t test -s out &&\n \t git gc --prune &&\n \t test $(git rev-parse master) = $(cd .. && git rev-parse master) &&\n \t git fsck --full)\n@@ -237,14 +255,17 @@ test_expect_success 'fetch with a non-applying branch.<name>.merge' '\n \tgit config branch.master.merge refs/heads/bigfoot &&\n \tgit config remote.blub.url one &&\n \tgit config remote.blub.fetch \"refs/heads/*:refs/remotes/one/*\" &&\n-\tgit fetch blub\n+\tgit fetch blub >out 2>err &&\n+\ttest ! -s err &&\n+\ttest -s out\n '\n \n # the strange name is: a\\!'b\n test_expect_success 'quoting of a strangely named repo' '\n-\ttest_must_fail git fetch \"a\\\\!'\\''b\" > result 2>&1 &&\n-\tcat result &&\n-\tgrep \"fatal: '\\''a\\\\\\\\!'\\''b'\\''\" result\n+\ttest_must_fail git fetch \"a\\\\!'\\''b\" >out 2>err &&\n+\ttest -s err &&\n+\ttest ! -s out &&\n+\tgrep \"fatal: '\\''a\\\\\\\\!'\\''b'\\''\" err\n '\n \n test_expect_success 'bundle should record HEAD correctly' '\n@@ -267,7 +288,9 @@ test_expect_success 'explicit fetch should not update tracking' '\n \t(\n \t\tcd three &&\n \t\to=$(git rev-parse --verify refs/remotes/origin/master) &&\n-\t\tgit fetch origin master &&\n+\t\tgit fetch origin master >out 2>err &&\n+\t\ttest ! -s err &&\n+\t\ttest -s out &&\n \t\tn=$(git rev-parse --verify refs/remotes/origin/master) &&\n \t\ttest \"$o\" = \"$n\" &&\n \t\ttest_must_fail git rev-parse --verify refs/remotes/origin/side\n@@ -295,7 +318,9 @@ test_expect_success 'configured fetch updates tracking' '\n \t(\n \t\tcd three &&\n \t\to=$(git rev-parse --verify refs/remotes/origin/master) &&\n-\t\tgit fetch origin &&\n+\t\tgit fetch origin  >out 2>err &&\n+\t\ttest ! -s err &&\n+\t\ttest -s out &&\n \t\tn=$(git rev-parse --verify refs/remotes/origin/master) &&\n \t\ttest \"$o\" != \"$n\" &&\n \t\tgit rev-parse --verify refs/remotes/origin/side\ndiff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh\nindex 1b06691..7ec36e7 100755\n--- a/t/t5521-pull-options.sh\n+++ b/t/t5521-pull-options.sh\n@@ -23,16 +23,16 @@ test_expect_success 'git pull' '\n \tmkdir cloned &&\n \t(cd cloned && git init &&\n \tgit pull \"../parent\" >out 2>err &&\n-\ttest -s err &&\n-\ttest ! -s out)\n+\ttest ! -s err &&\n+\ttest -s out)\n '\n \n test_expect_success 'git pull -v' '\n \tmkdir clonedv &&\n \t(cd clonedv && git init &&\n \tgit pull -v \"../parent\" >out 2>err &&\n-\ttest -s err &&\n-\ttest ! -s out)\n+\ttest ! -s err &&\n+\ttest -s out)\n '\n \n test_expect_success 'git pull -v -q' '\n@@ -47,8 +47,8 @@ test_expect_success 'git pull -q -v' '\n \tmkdir clonedqv &&\n \t(cd clonedqv && git init &&\n \tgit pull -q -v \"../parent\" >out 2>err &&\n-\ttest ! -s out &&\n-\ttest -s err)\n+\ttest ! -s err &&\n+\ttest -s out)\n '\n \n test_expect_success 'git pull --force' '\n-- \n1.7.1.251.g92a7\n"},{"id":"144257","messageId":"7v1vbvkorf.fsf@alter.siamese.dyndns.org","threadId":"23596","inReplyTo":"1277418881-11286-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH] fetch: don't output non-errors on stderr","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-06-25T17:25:56Z","receivedAt":"2010-06-25T17:25:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> Before the change error messages were drowned out by git-fetch's\n> non-error update notices, which didn't need my attention.\n\nI don't understand this part; care to elaborate?\n"},{"id":"144267","messageId":"AANLkTilToJ2ekKVgIeka5qx9_lasw6DKSy8bOhTrP4dC@mail.gmail.com","threadId":"23596","inReplyTo":"7v1vbvkorf.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] fetch: don't output non-errors on stderr","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-06-25T21:28:16Z","receivedAt":"2010-06-25T21:28:16Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Jun 25, 2010 at 17:25, Junio C Hamano <gitster@pobox.com> wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> Before the change error messages were drowned out by git-fetch's\n>> non-error update notices, which didn't need my attention.\n>\n> I don't understand this part; care to elaborate?\n\nI have a cron job (github-backup) that calls git fetch. Without this\npatch I have to run it as '> /dev/null 2>&1' and just rely on the exit\ncode, with it I can just do '> /dev/null' and not ignore stderr,\nbecause non-error output isn't being sent there anymore.\n\nIn short, the current git-fetch breaks the conventional *nix\nassumption that stderr only contains errors. With this patch errors go\nto stderr and normal output to stdout.\n"},{"id":"144270","messageId":"7v1vbukcu8.fsf@alter.siamese.dyndns.org","threadId":"23596","inReplyTo":"AANLkTilToJ2ekKVgIeka5qx9_lasw6DKSy8bOhTrP4dC@mail.gmail.com","subject":"Re: [PATCH] fetch: don't output non-errors on stderr","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-06-25T21:43:27Z","receivedAt":"2010-06-25T21:43:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> On Fri, Jun 25, 2010 at 17:25, Junio C Hamano <gitster@pobox.com> wrote:\n>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>>\n>>> Before the change error messages were drowned out by git-fetch's\n>>> non-error update notices, which didn't need my attention.\n>>\n>> I don't understand this part; care to elaborate?\n>\n> I have a cron job (github-backup) that calls git fetch. Without this\n> patch I have to run it as '> /dev/null 2>&1' and just rely on the exit\n> code,\n\nSignaling failure with exit code is _the_ standard practice, no?\n\nSome people seem to think unclean standard error means some error (most\nnotably tcl ;-), but I think they are mistaken.\n\nNot that I care too much about this issue, though.  I might end up queuing\nit, but we need to think about things like advice messages and such\n(e.g. 011fe98 (git-push: fix an advice message so it goes to stderr,\n2010-02-26)).\n"},{"id":"144285","messageId":"20100626061305.GB10290@coredump.intra.peff.net","threadId":"23596","inReplyTo":"7v1vbukcu8.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] fetch: don't output non-errors on stderr","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-06-26T06:13:05Z","receivedAt":"2010-06-26T06:13:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 25, 2010 at 02:43:27PM -0700, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n> \n> > On Fri, Jun 25, 2010 at 17:25, Junio C Hamano <gitster@pobox.com> wrote:\n> >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n> >>\n> >>> Before the change error messages were drowned out by git-fetch's\n> >>> non-error update notices, which didn't need my attention.\n> >>\n> >> I don't understand this part; care to elaborate?\n> >\n> > I have a cron job (github-backup) that calls git fetch. Without this\n> > patch I have to run it as '> /dev/null 2>&1' and just rely on the exit\n> > code,\n> \n> Signaling failure with exit code is _the_ standard practice, no?\n> \n> Some people seem to think unclean standard error means some error (most\n> notably tcl ;-), but I think they are mistaken.\n\nAgreed. I thought it was intentional for any human-readable progress\nmessages go to stderr. It is true in the case of git-fetch that stdout\nis not being used for anything, but:\n\n  1. Git should be consistent about where output goes. And other\n     programs may actually produce useful output on stdout, which should\n     not be mixed with human-readable verbose messages. For the sake of\n     those programs, we should be consistent about sending the output to\n     stderr.\n\n  2. Fetch may be combined with other operations in script. Consider\n     this toy script to print the latest origin/master to stdout:\n\n       #!/bin/sh\n       git fetch && git rev-parse origin/master\n\n     The user sees verbose cruft on stderr, but the interesting part is\n     on stdout. With your patch, the script is now broken. Yes, it's\n     obviously a toy, but I don't think it inconceivable that somebody\n     would not want fetch unexpectedly polluting their stdout. Even if\n     it would have been a better behavior in the first place (which I\n     don't agree with), changing it now means breaking scripts.\n\nThe real problem is that git is very chatty compared to other unix\nprograms. Most produce no output at all unless there is an error, or\nhuman-readable non-error output on stderr only if it is a tty. We do\nthis already with progress meters, and this output is just another form\nof progress update. So I think a patch to quell the status table when\nstderr is not a tty would be better (that still can break some scripts,\ntoo, but I am less sympathetic to people trying to save and parse\nhuman-readable stderr messages).\n\nOr even easier: is there a reason that \"git fetch -q\" would not do what\nyou (Ævar) want?\n\n-Peff\n"},{"id":"144297","messageId":"AANLkTik6jbcOtyXJ5JJav1xnLEO6RSmYTHpsX6yYaB5_@mail.gmail.com","threadId":"23596","inReplyTo":"20100626061305.GB10290@coredump.intra.peff.net","subject":"Re: [PATCH] fetch: don't output non-errors on stderr","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-06-26T12:14:59Z","receivedAt":"2010-06-26T12:14:59Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, Jun 26, 2010 at 06:13, Jeff King <peff@peff.net> wrote:\n\n> Or even easier: is there a reason that \"git fetch -q\" would not do what\n> you (Ævar) want?\n\nThat'd reduce the verbosity level, which'd skip some messages that I\nmight want. E.g.:\n\n\t\tif (verbosity >= 0) {\n\t\t\tfprintf(stderr, \" x %-*s %-*s -> %s\\n\",\n\t\t\t\tTRANSPORT_SUMMARY_WIDTH, \"[deleted]\",\n\t\t\t\tREFCOL_WIDTH, \"(none)\", prettify_refname(ref->name));\n\nAnyway, it looks like the only correct way to do this with Git in\ngeneral is to:\n\n    1. Capture stderr and stdout\n    2. Check the exit code, and if it's non-zero print both\n\nBut it sounds like we need some general discussion on what stdout and\nstderr should be used for in Git with regards to progress messages,\nerrors and other similar things.\n"},{"id":"144314","messageId":"AANLkTikq4z5Qs6UUnSh8T9GjVTJBdH8Wy3djIIOlrs2Y@mail.gmail.com","threadId":"23596","inReplyTo":"AANLkTik6jbcOtyXJ5JJav1xnLEO6RSmYTHpsX6yYaB5_@mail.gmail.com","subject":"Re: [PATCH] fetch: don't output non-errors on stderr","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2010-06-26T13:40:24Z","receivedAt":"2010-06-26T13:40:24Z","isPatch":true,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\nOn Sat, Jun 26, 2010 at 8:14 PM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> But it sounds like we need some general discussion on what stdout and\n> stderr should be used for in Git with regards to progress messages,\n> errors and other similar things.\n\nI'd say - submit a patch for the style guide with your proposed\nguidelines on stdout and stderr usage.\n\n-- \nCheers,\nRay Chuan\n"},{"id":"144318","messageId":"AANLkTikxJ_MDLhQFweRMWvhzJy9QIfyuJTYaY4a2tPwS@mail.gmail.com","threadId":"23596","inReplyTo":"AANLkTikq4z5Qs6UUnSh8T9GjVTJBdH8Wy3djIIOlrs2Y@mail.gmail.com","subject":"Re: [PATCH] fetch: don't output non-errors on stderr","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-06-26T15:07:55Z","receivedAt":"2010-06-26T15:07:55Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, Jun 26, 2010 at 13:40, Tay Ray Chuan <rctay89@gmail.com> wrote:\n\n> On Sat, Jun 26, 2010 at 8:14 PM, Ævar Arnfjörð Bjarmason\n> <avarab@gmail.com> wrote:\n>> But it sounds like we need some general discussion on what stdout and\n>> stderr should be used for in Git with regards to progress messages,\n>> errors and other similar things.\n>\n> I'd say - submit a patch for the style guide with your proposed\n> guidelines on stdout and stderr usage.\n\nI'm not sure how such a guide should be like for the general case, but\nat least making commands internally consistent (as this patch does) is\none step in that direction.\n"},{"id":"144319","messageId":"20100626164618.GA18517@coredump.intra.peff.net","threadId":"23596","inReplyTo":"AANLkTik6jbcOtyXJ5JJav1xnLEO6RSmYTHpsX6yYaB5_@mail.gmail.com","subject":"Re: [PATCH] fetch: don't output non-errors on stderr","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-06-26T16:46:18Z","receivedAt":"2010-06-26T16:46:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jun 26, 2010 at 12:14:59PM +0000, Ævar Arnfjörð Bjarmason wrote:\n\n> On Sat, Jun 26, 2010 at 06:13, Jeff King <peff@peff.net> wrote:\n> \n> > Or even easier: is there a reason that \"git fetch -q\" would not do what\n> > you (Ævar) want?\n> \n> That'd reduce the verbosity level, which'd skip some messages that I\n> might want. E.g.:\n> \n> \t\tif (verbosity >= 0) {\n> \t\t\tfprintf(stderr, \" x %-*s %-*s -> %s\\n\",\n> \t\t\t\tTRANSPORT_SUMMARY_WIDTH, \"[deleted]\",\n> \t\t\t\tREFCOL_WIDTH, \"(none)\", prettify_refname(ref->name));\n\nWait, what? Isn't that line also part of the same human-readable status\ntable? What makes the status of a pruned ref any different than the\nstatus of an updated ref? I don't see how that is an error message, but\nthe other lines are not.\n\n-Peff\n"},{"id":"144320","messageId":"AANLkTinOHlHgb1GrHPZrC8Rs0l4XNNf8lqRvhRaWPVPz@mail.gmail.com","threadId":"23596","inReplyTo":"20100626164618.GA18517@coredump.intra.peff.net","subject":"Re: [PATCH] fetch: don't output non-errors on stderr","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-06-26T16:50:30Z","receivedAt":"2010-06-26T16:50:30Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, Jun 26, 2010 at 16:46, Jeff King <peff@peff.net> wrote:\n> On Sat, Jun 26, 2010 at 12:14:59PM +0000, Ævar Arnfjörð Bjarmason wrote:\n>\n>> On Sat, Jun 26, 2010 at 06:13, Jeff King <peff@peff.net> wrote:\n>>\n>> > Or even easier: is there a reason that \"git fetch -q\" would not do what\n>> > you (Ævar) want?\n>>\n>> That'd reduce the verbosity level, which'd skip some messages that I\n>> might want. E.g.:\n>>\n>>               if (verbosity >= 0) {\n>>                       fprintf(stderr, \" x %-*s %-*s -> %s\\n\",\n>>                               TRANSPORT_SUMMARY_WIDTH, \"[deleted]\",\n>>                               REFCOL_WIDTH, \"(none)\", prettify_refname(ref->name));\n>\n> Wait, what? Isn't that line also part of the same human-readable status\n> table? What makes the status of a pruned ref any different than the\n> status of an updated ref? I don't see how that is an error message, but\n> the other lines are not.\n\nI misread that and picked the wrong example, sorry for the noise.\n"}]}