* "--quiet" for git-push does not suppress remote hook output
@ 2020-05-07 12:05 Laszlo Ersek
2020-05-07 12:16 ` Laszlo Ersek
0 siblings, 1 reply; 4+ messages in thread
From: Laszlo Ersek @ 2020-05-07 12:05 UTC (permalink / raw)
To: public git mailing list
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).
Thanks!
Laszlo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: "--quiet" for git-push does not suppress remote hook output
2020-05-07 12:05 "--quiet" for git-push does not suppress remote hook output Laszlo Ersek
@ 2020-05-07 12:16 ` Laszlo Ersek
2020-05-07 21:02 ` Jeff King
0 siblings, 1 reply; 4+ messages in thread
From: Laszlo Ersek @ 2020-05-07 12:16 UTC (permalink / raw)
To: public git mailing list
(Sorry about the self-followup...)
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).
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?
Thanks!
Laszlo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: "--quiet" for git-push does not suppress remote hook output
2020-05-07 12:16 ` Laszlo Ersek
@ 2020-05-07 21:02 ` Jeff King
2020-05-08 9:50 ` Laszlo Ersek
0 siblings, 1 reply; 4+ messages in thread
From: Jeff King @ 2020-05-07 21:02 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: public git mailing list
On Thu, May 07, 2020 at 02:16:36PM +0200, Laszlo Ersek wrote:
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: "--quiet" for git-push does not suppress remote hook output
2020-05-07 21:02 ` Jeff King
@ 2020-05-08 9:50 ` Laszlo Ersek
0 siblings, 0 replies; 4+ messages in thread
From: Laszlo Ersek @ 2020-05-08 9:50 UTC (permalink / raw)
To: Jeff King; +Cc: public git mailing list
On 05/07/20 23:02, Jeff King wrote:
> On Thu, May 07, 2020 at 02:16:36PM +0200, Laszlo Ersek wrote:
>
>> 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).
Thank you for explaining!
Laszlo
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-05-08 9:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-07 12:05 "--quiet" for git-push does not suppress remote hook output Laszlo Ersek
2020-05-07 12:16 ` Laszlo Ersek
2020-05-07 21:02 ` Jeff King
2020-05-08 9:50 ` Laszlo Ersek
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.