]> Kevux Git Server - rit/commit
t9300: work around partial read bug in Dash v0.5.13
authorPatrick Steinhardt <ps@pks.im>
Thu, 2 Apr 2026 06:51:19 +0000 (08:51 +0200)
committerJunio C Hamano <gitster@pobox.com>
Thu, 2 Apr 2026 18:39:42 +0000 (11:39 -0700)
commitd48c5d5a4c801dfe9acd5dc4a3c1b94430883f52
tree31f7cecdaa7fb50e03b3c8d0829eea8b52232f69
parent0c8424c259b417c6aadc23f5398e55edd7b047a2
t9300: work around partial read bug in Dash v0.5.13

When executing t9300 with Dash v0.5.13.1 we can see that the test hangs
completely with the following (condensed) trace:

  git fast-import
  + error=1
  + read output
  + cat input
  + echo checkpoint
  + echo progress checkpoint
  + test rogress checkpoint = progress checkpoint
  + test rogress checkpoint = UNEXPECTED
  + echo cruft: rogress checkpoint
  cruft: rogress checkpoint
  + read output
  + test  = progress checkpoint
  + test  = UNEXPECTED
  + echo cruft:
  cruft:
  + read output

Basically, what's happening here is that we spawn git-fast-import(1) and
wait for it to output a certain string, "progress checkpoint". Curiously
though, what we end up reading is "rogress checkpoint" -- so the first
byte of the expected string is missing.

Same as in the preceding commit, this seems to be a bug in Dash itself
that bisects to c5bf970 (expand: Add multi-byte support to pmatch,
2024-06-02). But other than in the preceding commit, this bug has
already been fixed upstream in 079059a (input: Fix heap-buffer-overflow
in preadbuffer on long lines, 2026-02-11), which is part of v0.5.13.2.

For now though, work around the bug by waiting for the expected output
in a different way. There is no good reason why one version should work
better than the other, but at least the new version doesn't exhibit the
bug. And, if you ask me, it's also slightly easier to read.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t9300-fast-import.sh