Junio C Hamano [off-list ref] writes:
Yuck; please discard the previous one. write_in_full() side is also
writing into that process, so we should do the same.
OK, without these two, and with the "true" filter that does not read
anything reinstated in the test script, t0021 used to die
i=0; while sh t0021-conversion.sh; do i=$(( $i + 1 )); done
after 150 iteration or so for me. With these two, it seems to go on
without breaking (I bored after 1000 iterations), so I'd declare it
good enough ;-)
On Tue, May 19, 2015 at 12:48:21PM -0700, Junio C Hamano wrote:
Junio C Hamano [off-list ref] writes:
quoted
Yuck; please discard the previous one. write_in_full() side is also
writing into that process, so we should do the same.
OK, without these two, and with the "true" filter that does not read
anything reinstated in the test script, t0021 used to die
i=0; while sh t0021-conversion.sh; do i=$(( $i + 1 )); done
after 150 iteration or so for me. With these two, it seems to go on
without breaking (I bored after 1000 iterations), so I'd declare it
good enough ;-)
Your revised patch 2 looks good to me. I think you could test it more
reliably by simply adding a larger file, like:
test-genrandom foo $((128 * 1024 + 1)) >big &&
echo 'big filter=epipe' >.gitattributes &&
git config filter.epipe.clean true &&
git add big
The worst case if you get the size of the pipe buffer too small is that
the test will erroneously pass, but that is OK. As long as one person
has a reasonable-sized buffer, they will complain to the list
eventually. :)
-Peff