From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Glen Choo <chooglen@google.com>,
git@vger.kernel.org,
Adam Zethraeus <adam.zethraeus@includedhealth.com>
Subject: Re: bug report: pre-commit & pre-push hook output is redirected differently
Date: Thu, 07 Jul 2022 14:40:49 +0200 [thread overview]
Message-ID: <220707.86tu7t84zh.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqa69mgdde.fsf@gitster.g>
On Wed, Jul 06 2022, Junio C Hamano wrote:
> Adam Zethraeus <adam.zethraeus@includedhealth.com> writes:
>
>> What did you do before the bug happened? (Steps to reproduce your issue)
>>
>> Installed identical pre-commit and pre-push hooks:
>>
>> ```
>> #!/bin/bash
>>
>>>&1 echo "stdout"
>>>&2 echo "stderr"
>> exit 1
>> ```
>>
>> What did you expect to happen? (Expected behavior)
>>
>> `git push` and `git commit` should have the same hook behavior.
>>
>> What happened instead? (Actual behavior)
>>
>> The pre-commit hook was run with stdout redirected to stderr but the
>> pre-push hook's output was unaltered.
>
> Without looking into it very much, the output of hooks is an area
> with known regression at 2.36, so let me redirect it to those who
> are likely to know it ;-)
>
> Thanks for a report.
I may be missing something, but I think this report has nothing to do
with any recent changes or regressions, but is merely noting a behavior
change between pre-push and some other hooks that we've had since 1.8.2,
or since the "pre-push" hook was added in ec55559f937 (push: Add support
for pre-push hooks, 2013-01-13).
I tested this with a local v2.30.0, and the behavior was the same.
This will "fix" it:
diff --git a/transport.c b/transport.c
index 52db7a3cb09..0cc7d05e0da 100644
--- a/transport.c
+++ b/transport.c
@@ -1225,6 +1225,7 @@ static int run_pre_push_hook(struct transport *transport,
strvec_push(&proc.args, transport->url);
proc.in = -1;
+ proc.stdout_to_stderr = 1;
proc.trace2_hook_name = "pre-push";
if (start_command(&proc)) {
But whether that's a fix or not depends on whether we think we should
make this behavior consistent. I tend to think so, but it would be a
behavior change to long-established behavior in pre-push.
It *is* something we need to be careful of when converting the rest of
the hooks to the hooks API, i.e. we need tests for how stderr/stdout is
handled for each one.
But this being different is just because some hook use the hook.c API
(and before that the helper in run-command.c), and others use "struct
child_process" or whatever explicitly (such as "pre-push").
Since it's up to each callsite to set up the "proc" (or equivalent) some
supply "stdout_to_stderr", some don't.
From some quick grepping it seems the odd ones out are pre-push and
proc-receive, but I only skimmed a "git grep" to find the second one,
and may have missed others.
next prev parent reply other threads:[~2022-07-07 12:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-06 20:40 bug report: pre-commit & pre-push hook output is redirected differently Adam Zethraeus
2022-07-06 21:06 ` Junio C Hamano
2022-07-07 12:40 ` Ævar Arnfjörð Bjarmason [this message]
2022-07-07 16:57 ` Junio C Hamano
2022-07-07 20:55 ` Emily Shaffer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=220707.86tu7t84zh.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=adam.zethraeus@includedhealth.com \
--cc=chooglen@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.