Re: pre-push hooks and stdout regression

> On Mon, 12 Jan 2026, Chris Darroch <chrisd@apache.org> wrote:
>> Hello --
>>
>>    I'm one of the current maintainers of the Git LFS project, and we
>> happened to notice that a recent change in Git's "master" branch has
>> introduced a regression in our test suite.
>>
>>    Specifically, with commit 3e2836a742d8b2b2da25ca06e9d0ac3a539bd966
>> ("transport: convert pre-push to hook API") from the "ar/run-command-hook"
>> merged last week, it appears that when a pre-push hook such as our
>> git-lfs-pre-push program runs, messages it writes to its standard output
>> are now delivered to the user's standard error stream instead of
>> their standard output stream.
>>
>>    I suspect this is because the pick_next_hook() function in hook.c
>> sets the stdout_to_stderr flag for its "cb" child_process argument,
>> and that function is now used to run the pre-push hook.
>>
>>    Arguably, the Git LFS pre-push hook program should write its
>> progress meter messages to stderr, but since at least 2017 it appears
>> we have used stdout for this purpose:
>>
>> https://github.com/git-lfs/git-lfs/commit/d665f7d725150761fe3b196da2c2d4448f7d2c61
>> https://github.com/git-lfs/git-lfs/pull/2732
>>
>>    We can certainly work around this change in the Git LFS test suite,
>> since our progress messages are still output by Git, just to stderr
>> instead of stdout.
>>
>>    However, I think there remains the larger concern that users who
>> depend on the existing Git pre-push behaviour in some way may also
>> encounter regressions, perhaps because they expect (as our test suite
>> does) to see certain messages either output or not output to stderr
>> during a Git push operation.
>>
>>    Please do let me know your thoughts on this subject!  If the
>> consensus is that the new behaviour is correct, we'll adjust our test
>> suite to match it, but I'll wait to hear the outcome of any discussion
>> before making that change.
>>
>>    Thank you again and all the best,
>
> Thank you for reporting this, it's exactly the kind of regressions I'm
> looking for and the reason I did the "Extending git without breaking it"
> presentation during the mini-summit a few months ago (video should be
> online).
>
> I tend to agree with Brian that going back to the previous behavior is
> best for now, maybe schedule a breaking change or extension to make
> hooks to print to stderr instead of stdout.
>
> I will test this on my parallel config based hooks topic towards which
> this conversion is building up to and send a patch or report back ASAP.
>
> Of course I will also run the git LFS test suite to confirm the
> regression and the fix.