public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Darroch <chrisd@apache.org>
To: git@vger.kernel.org
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	Chris Darroch <chrisd8088@github.com>
Subject: pre-push hooks and stdout regression
Date: Mon, 12 Jan 2026 15:21:42 -0800	[thread overview]
Message-ID: <ab578804-891e-edcc-12a6-8b1030d1bacb@apache.org> (raw)

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,

Chris.

-- 
GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820  6715 F54F E648 0883 35A9


             reply	other threads:[~2026-01-12 23:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-12 23:21 Chris Darroch [this message]
2026-01-13  2:12 ` pre-push hooks and stdout regression brian m. carlson
2026-01-13  9:49 ` Adrian Ratiu
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=ab578804-891e-edcc-12a6-8b1030d1bacb@apache.org \
    --to=chrisd@apache.org \
    --cc=chrisd8088@github.com \
    --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