From: Adrian Ratiu Date: Tue, 13 Jan 2026 09:49:14 GMT Subject: Re: pre-push hooks and stdout regression Message-ID: <87y0m1onad.fsf@gentoo.mail-host-address-is-not-set> In-Reply-To: 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.