Re: "--quiet" for git-push does not suppress remote hook output

From: Jeff King <peff@peff.net>
Date: May 7, 2020, 21:02 UTC
Message-ID: <20200507210210.GB38308@coredump.intra.peff.net>
In-Reply-To: <3cb011a9-ce3d-df38-01c6-062062f1c9c2@redhat.com>

On Thu, May 07, 2020 at 02:16:36PM +0200, Laszlo Ersek wrote:

Show 13 quoted lines

> On 05/07/20 14:05, Laszlo Ersek wrote:
> > Hi,
> > 
> > being a total novice in git internals, it seems like
> > "builtin/receive-pack.c" (on the server) forwards any receive hook
> > output with copy_to_sideband() back to git-push (on the client), even if
> > git-push was invoked with "--quiet".
> > 
> > And "case 2" in demultiplex_sideband() seems to print that "band" to
> > stderr (on the client), despite "--quiet".
> > 
> > Is this intentional? I'd prefer "git push --quiet" to suppress remote
> > hook output (unless the remote hook fails).

I think the client has to propagate sideband 2 from the server, since it doesn't know whether the messages are informational or errors (and even with --quiet, we'd want to show errors).

There is a "quiet" protocol capability; when you run "git push --quiet" on the client, it tells the server to use "quiet", and then it passes options to index-pack, etc, to suppress progress. But that never makes it to hooks.

> Or else:
> 
> would it be the job of the particular receive hooks to observe and obey
> the "--quiet" option in the GIT_PUSH_OPTION_* environment variables?

That would work, but push options require the client to send them. We should probably be passing knowledge of the "quiet" capability from receive-pack down to the hooks, probably via an environment variable (but not GIT_PUSH_OPTION_*, because that already has meaning).

-Peff