From: Jeff King <peff@peff•net>
To: Adrian Ratiu <adrian.ratiu@collabora•com>
Cc: git@vger•kernel.org, Junio C Hamano <gitster@pobox•com>,
Patrick Steinhardt <ps@pks•im>,
Emily Shaffer <emilyshaffer@google•com>,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail•com>,
Chris Darroch <chrisd@apache•org>,
"brian m. carlson" <sandals@crustytoothpaste•net>
Subject: Re: [PATCH v2] hook: allow hooks to disable stdout_to_stderr
Date: Wed, 14 Jan 2026 12:19:29 -0500 [thread overview]
Message-ID: <20260114171929.GC885771@coredump.intra.peff.net> (raw)
In-Reply-To: <20260114170849.GB885771@coredump.intra.peff.net>
On Wed, Jan 14, 2026 at 12:08:49PM -0500, Jeff King wrote:
> I looked at what feed_receive_hook_cb() is doing and...it's kind of
> horrifying. It arbitrarily sends 500 lines, and then yields to the
> caller to pump stderr (assuming ungroup=0). So:
>
> 1. It is assuming that 500 lines of input won't fill up the pipe
> buffer and block. Even if we compute the size of 500 lines we're
> sending, we don't know if the caller has cleared anything from the
> pipe in the last call. There might be zero bytes available!
>
> 2. After 500 lines we'll go back to the caller, which will then
> poll(). But if there's nothing to read on stderr, it will wait for
> the 100ms timeout. So if you have, say, 501 lines to send, then
> there will be a pointless 100ms pause in the middle.
>
> So here's an example hook setup that will deadlock due to (1):
And just for fun, here's an example that shows problem (2):
-- >8 --
rm -rf repo
git init repo
cd repo
git commit --allow-empty -m foo
git init --bare dst.git
cat >dst.git/hooks/pre-receive <<\EOF
#!/bin/sh
# We don't even need to do anything interesting here! Git
# will send us 500 lines, then block waiting for stderr which
# we'll never send, and then send us another batch of 500.
cat >/dev/null
EOF
chmod +x dst.git/hooks/pre-receive
# Now do a moderate push of 500 branches.
seq --format='create refs/heads/small-%g HEAD' 500 |
git update-ref --stdin
time git push -q dst.git refs/heads/small-*
# And compare with one that sends just one more.
seq --format='create refs/heads/large-%g HEAD' 501 |
git update-ref --stdin
time git push -q dst.git refs/heads/large-*
-- >8 --
The second push always takes 100ms more! If we run the server side under
strace by replacing the final line with this:
git push -q --receive-pack='strace -T git-receive-pack' dst.git refs/heads/large-*
we can see the stall here as we write to the hook:
write(4, "00000000000000000000000000000000"..., 51393) = 51393 <0.000011>
poll([{fd=5, events=POLLIN|POLLHUP}], 1, 100) = 0 (Timeout) <0.100506>
write(4, "00000000000000000000000000000000"..., 102) = 102 <0.000057>
That would likewise be solved by using ungroup=1 (in which case we do
not poll, but just call the feed function immediately again) or by using
a real poll() loop (which would see immediately that the hook is ready
for more input, rather than hitting the 100ms timeout).
-Peff
next prev parent reply other threads:[~2026-01-14 17:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 11:56 [PATCH] hook: make stdout_to_stderr optional Adrian Ratiu
2026-01-13 13:36 ` Patrick Steinhardt
2026-01-13 13:55 ` Adrian Ratiu
2026-01-13 14:00 ` Junio C Hamano
2026-01-13 14:06 ` Junio C Hamano
2026-01-13 14:59 ` Adrian Ratiu
2026-01-13 15:22 ` Junio C Hamano
2026-01-13 15:37 ` Adrian Ratiu
2026-01-13 14:11 ` Adrian Ratiu
2026-01-13 23:45 ` [PATCH v2] hook: allow hooks to disable stdout_to_stderr Adrian Ratiu
2026-01-14 3:12 ` Jeff King
2026-01-14 8:46 ` Adrian Ratiu
2026-01-14 8:59 ` Adrian Ratiu
2026-01-14 9:36 ` Kristoffer Haugsbakk
2026-01-14 17:08 ` Jeff King
2026-01-14 17:19 ` Jeff King [this message]
2026-01-14 17:56 ` Adrian Ratiu
2026-01-14 6:13 ` Kristoffer Haugsbakk
2026-01-14 18:57 ` [PATCH v3 0/2] Fix two hook conversion regressions Adrian Ratiu
2026-01-14 18:57 ` [PATCH v3 1/2] hook: allow hooks to disable stdout_to_stderr Adrian Ratiu
2026-01-14 18:57 ` [PATCH v3 2/2] hook: make ungroup opt-out instead of opt-in Adrian Ratiu
2026-01-14 21:27 ` Jeff King
2026-01-14 22:45 ` Adrian Ratiu
2026-01-18 8:44 ` Kristoffer Haugsbakk
2026-01-15 14:15 ` [PATCH v3 0/2] Fix two hook conversion regressions Junio C Hamano
2026-01-15 17:19 ` Adrian Ratiu
2026-01-15 17:33 ` Junio C Hamano
2026-01-15 17:53 ` Adrian Ratiu
2026-01-15 20:27 ` Junio C Hamano
2026-01-15 21:24 ` Adrian Ratiu
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=20260114171929.GC885771@coredump.intra.peff.net \
--to=peff@peff$(echo .)net \
--cc=adrian.ratiu@collabora$(echo .)com \
--cc=chrisd@apache$(echo .)org \
--cc=emilyshaffer@google$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=kristofferhaugsbakk@fastmail$(echo .)com \
--cc=ps@pks$(echo .)im \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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