From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 16 Mar 2026 18:44:32 GMT
Subject: Re: [PATCH v3 8/9] hook: introduce extensions.hookStdoutToStderr
Message-ID: <xmqqy0jrobqn.fsf@gitster.g>
In-Reply-To: <20260309133739.294555-9-adrian.ratiu@collabora.com>

Adrian Ratiu <adrian.ratiu@collabora.com> writes:

> All hooks already redirect stdout to stderr with the exception of
> pre-push which has a known user who depends on the separate stdout
> versus stderr outputs (the git-lfs project).
>
> The pre-push behavior was a surprise which we found out about after
> causing a regression for git-lfs. Notably, it might not be the only
> exception (it's the one we know about). There might be more.
>
> This presents a challenge because stdout_to_stderr is required for
> hook parallelization, so run-command can buffer and de-interleave
> the hook outputs using ungroup=0, when hook.jobs > 1.
>
> Introduce an extension to enforce consistency: all hooks merge stdout
> into stderr and can be safely parallelized. This provides a clean
> separation and avoids breaking existing stdout vs stderr behavior.
>
> When this extension is disabled, the `hook.jobs` config has no
> effect for pre-push, to prevent garbled (interleaved) parallel
> output, so it runs sequentially like before.
>
> Alternatives I've considered to this extension include:
> 1. Allowing pre-push to run in parallel with interleaved output.
> 2. Always running pre-push sequentially (no parallel jobs for it).
> 3. Making users (only git-lfs? maybe more?) fix their hooks to read
>    stderr not stdout.
>
> Out of all these alternatives, I think this extension is the most
> reasonable compromise, to not break existing users, allow pre-push
> parallel jobs for those who need it (with correct outputs) and also
> future-proofing in case there are any more exceptions to be added.

Hmph, I am a bit surprised that this is not hook.<name>.stdoutToStderr
controlled per hook process.

If we already have consensus that giving output to stdout is a
historical wart that we would rather want to fix, then this
configuration is probably good enough.  It is certainly a much
simpler approach, and there is no need to make finer-grained
customization available when nobody wants it ;-).

We may also want to consider "fixing" it at Git 3.0 boundary, if
that is the case, though?  I dunno.  I weren't following the
discussion closely enough to tell myself.

Thanks.