From: Adrian Ratiu Date: Tue, 13 Jan 2026 12:31:35 GMT Subject: Re: pre-push hooks and stdout regression Message-ID: <87pl7diti0.fsf@gentoo.mail-host-address-is-not-set> In-Reply-To: <87y0m1onad.fsf@gentoo.mail-host-address-is-not-set> On Tue, 13 Jan 2026, Adrian Ratiu wrote: > On Mon, 12 Jan 2026, Chris Darroch 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. I couldn't reproduce the git-lfs test failure using the public tests from the git-lfs repo (they always pass), however this patch should fix it: https://lore.kernel.org/git/20260113115633.230479-1-adrian.ratiu@collabora.com/T/#u Chris or Brian, can you please confirm if it works? Much appreciated.