* "--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.