{"thread":{"id":"53424","subject":"\"--quiet\" for git-push does not suppress remote hook output","startedAt":"2020-05-07T12:05:11Z","lastAt":"2020-05-08T09:51:01Z","messageCount":4,"participants":["Laszlo Ersek","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"397287","messageId":"ba70b25b-906c-0117-2594-c606595c6816@redhat.com","threadId":"53424","inReplyTo":null,"subject":"\"--quiet\" for git-push does not suppress remote hook output","fromName":"Laszlo Ersek","fromEmail":"lersek@redhat.com","sentAt":"2020-05-07T12:05:05Z","receivedAt":"2020-05-07T12:05:11Z","isPatch":false,"sender":{"key":"lersek@redhat.com","avatar":null},"body":"Hi,\n\nbeing a total novice in git internals, it seems like\n\"builtin/receive-pack.c\" (on the server) forwards any receive hook\noutput with copy_to_sideband() back to git-push (on the client), even if\ngit-push was invoked with \"--quiet\".\n\nAnd \"case 2\" in demultiplex_sideband() seems to print that \"band\" to\nstderr (on the client), despite \"--quiet\".\n\nIs this intentional? I'd prefer \"git push --quiet\" to suppress remote\nhook output (unless the remote hook fails).\n\nThanks!\nLaszlo\n\n"},{"id":"397288","messageId":"3cb011a9-ce3d-df38-01c6-062062f1c9c2@redhat.com","threadId":"53424","inReplyTo":"ba70b25b-906c-0117-2594-c606595c6816@redhat.com","subject":"Re: \"--quiet\" for git-push does not suppress remote hook output","fromName":"Laszlo Ersek","fromEmail":"lersek@redhat.com","sentAt":"2020-05-07T12:16:36Z","receivedAt":"2020-05-07T12:16:42Z","isPatch":false,"sender":{"key":"lersek@redhat.com","avatar":null},"body":"(Sorry about the self-followup...)\n\nOn 05/07/20 14:05, Laszlo Ersek wrote:\n> Hi,\n> \n> being a total novice in git internals, it seems like\n> \"builtin/receive-pack.c\" (on the server) forwards any receive hook\n> output with copy_to_sideband() back to git-push (on the client), even if\n> git-push was invoked with \"--quiet\".\n> \n> And \"case 2\" in demultiplex_sideband() seems to print that \"band\" to\n> stderr (on the client), despite \"--quiet\".\n> \n> Is this intentional? I'd prefer \"git push --quiet\" to suppress remote\n> hook output (unless the remote hook fails).\n\nOr else:\n\nwould it be the job of the particular receive hooks to observe and obey\nthe \"--quiet\" option in the GIT_PUSH_OPTION_* environment variables?\n\nThanks!\nLaszlo\n\n"},{"id":"397356","messageId":"20200507210210.GB38308@coredump.intra.peff.net","threadId":"53424","inReplyTo":"3cb011a9-ce3d-df38-01c6-062062f1c9c2@redhat.com","subject":"Re: \"--quiet\" for git-push does not suppress remote hook output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-07T21:02:10Z","receivedAt":"2020-05-07T21:02:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 07, 2020 at 02:16:36PM +0200, Laszlo Ersek wrote:\n\n> On 05/07/20 14:05, Laszlo Ersek wrote:\n> > Hi,\n> > \n> > being a total novice in git internals, it seems like\n> > \"builtin/receive-pack.c\" (on the server) forwards any receive hook\n> > output with copy_to_sideband() back to git-push (on the client), even if\n> > git-push was invoked with \"--quiet\".\n> > \n> > And \"case 2\" in demultiplex_sideband() seems to print that \"band\" to\n> > stderr (on the client), despite \"--quiet\".\n> > \n> > Is this intentional? I'd prefer \"git push --quiet\" to suppress remote\n> > hook output (unless the remote hook fails).\n\nI think the client has to propagate sideband 2 from the server, since it\ndoesn't know whether the messages are informational or errors (and even\nwith --quiet, we'd want to show errors).\n\nThere is a \"quiet\" protocol capability; when you run \"git push --quiet\"\non the client, it tells the server to use \"quiet\", and then it passes\noptions to index-pack, etc, to suppress progress. But that never makes\nit to hooks.\n\n> Or else:\n> \n> would it be the job of the particular receive hooks to observe and obey\n> the \"--quiet\" option in the GIT_PUSH_OPTION_* environment variables?\n\nThat would work, but push options require the client to send them. We\nshould probably be passing knowledge of the \"quiet\" capability from\nreceive-pack down to the hooks, probably via an environment variable\n(but not GIT_PUSH_OPTION_*, because that already has meaning).\n\n-Peff\n"},{"id":"397397","messageId":"a9593a71-e1d0-54cc-d974-7cfb60deafc6@redhat.com","threadId":"53424","inReplyTo":"20200507210210.GB38308@coredump.intra.peff.net","subject":"Re: \"--quiet\" for git-push does not suppress remote hook output","fromName":"Laszlo Ersek","fromEmail":"lersek@redhat.com","sentAt":"2020-05-08T09:50:51Z","receivedAt":"2020-05-08T09:51:01Z","isPatch":false,"sender":{"key":"lersek@redhat.com","avatar":null},"body":"On 05/07/20 23:02, Jeff King wrote:\n> On Thu, May 07, 2020 at 02:16:36PM +0200, Laszlo Ersek wrote:\n> \n>> On 05/07/20 14:05, Laszlo Ersek wrote:\n>>> Hi,\n>>>\n>>> being a total novice in git internals, it seems like\n>>> \"builtin/receive-pack.c\" (on the server) forwards any receive hook\n>>> output with copy_to_sideband() back to git-push (on the client), even if\n>>> git-push was invoked with \"--quiet\".\n>>>\n>>> And \"case 2\" in demultiplex_sideband() seems to print that \"band\" to\n>>> stderr (on the client), despite \"--quiet\".\n>>>\n>>> Is this intentional? I'd prefer \"git push --quiet\" to suppress remote\n>>> hook output (unless the remote hook fails).\n> \n> I think the client has to propagate sideband 2 from the server, since it\n> doesn't know whether the messages are informational or errors (and even\n> with --quiet, we'd want to show errors).\n> \n> There is a \"quiet\" protocol capability; when you run \"git push --quiet\"\n> on the client, it tells the server to use \"quiet\", and then it passes\n> options to index-pack, etc, to suppress progress. But that never makes\n> it to hooks.\n> \n>> Or else:\n>>\n>> would it be the job of the particular receive hooks to observe and obey\n>> the \"--quiet\" option in the GIT_PUSH_OPTION_* environment variables?\n> \n> That would work, but push options require the client to send them. We\n> should probably be passing knowledge of the \"quiet\" capability from\n> receive-pack down to the hooks, probably via an environment variable\n> (but not GIT_PUSH_OPTION_*, because that already has meaning).\n\nThank you for explaining!\nLaszlo\n\n"}]}