From: Adrian Ratiu <adrian.ratiu@collabora.com>
To: Chris Darroch <chrisd@apache.org>, git@vger.kernel.org
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Chris Darroch <chrisd8088@github.com>
Subject: Re: pre-push hooks and stdout regression
Date: Tue, 13 Jan 2026 11:49:14 +0200 [thread overview]
Message-ID: <87y0m1onad.fsf@gentoo.mail-host-address-is-not-set> (raw)
In-Reply-To: <ab578804-891e-edcc-12a6-8b1030d1bacb@apache.org>
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.
next prev parent reply other threads:[~2026-01-13 9:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-12 23:21 pre-push hooks and stdout regression Chris Darroch
2026-01-13 2:12 ` brian m. carlson
2026-01-13 9:49 ` Adrian Ratiu [this message]
2026-01-13 12:31 ` Adrian Ratiu
2026-01-13 20:44 ` Chris Darroch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y0m1onad.fsf@gentoo.mail-host-address-is-not-set \
--to=adrian.ratiu@collabora.com \
--cc=chrisd8088@github.com \
--cc=chrisd@apache.org \
--cc=git@vger.kernel.org \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox