Re: pre-push hooks and stdout regression
- From
Adrian Ratiu <adrian.ratiu@collabora.com>
- Date
- Jan 13, 2026, 09:49 UTC
- Message-ID
- <87y0m1onad.fsf@gentoo.mail-host-address-is-not-set>
- In-Reply-To
- <ab578804-891e-edcc-12a6-8b1030d1bacb@apache.org>
On Mon, 12 Jan 2026, Chris Darroch <chrisd@apache.org> wrote:
Show 40 quoted lines
> 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.