aboutsummaryrefslogtreecommitdiff
path: root/Makefile
diff options
context:
space:
mode:
authorPatrick Steinhardt <ps@pks.im>2026-03-13 07:45:14 +0100
committerJunio C Hamano <gitster@pobox.com>2026-03-13 08:54:13 -0700
commitc422ec886c92d27b702a2b8cf657cede54658d94 (patch)
treeb741c96caaba287dab3f3b6eebc0e9ec55eb2d06 /Makefile
parent5d4b7ddce15950ed71ec60453aadfe13d9e633d5 (diff)
downloadgit-c422ec886c92d27b702a2b8cf657cede54658d94.tar.xz
upload-pack: prefer flushing data over sending keepalive
When using the sideband in git-upload-pack(1) we know to send out keepalive packets in case generating the pack takes too long. These keepalives take the form of a simple empty pktline. In the preceding commit we have adapted git-upload-pack(1) to buffer data more aggressively before sending it to the client. This creates an obvious optimization opportunity: when we hit the keepalive timeout while we still hold on to some buffered data, then it makes more sense to flush out the data instead of sending the empty keepalive packet. This is overall not going to be a significant win. Most keepalives will come before the pack data starts, and once pack-objects starts producing data, it tends to do so pretty consistently. And of course we can't send data before we see the PACK header, because the whole point is to buffer the early bit waiting for packfile URIs. But the optimization is easy enough to realize. Do so and flush out data instead of sending an empty pktline. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions