On 29/09/16 12:28, Lars Schneider wrote:
On 28 Sep 2016, at 23:49, Junio C Hamano <gitster@xxxxxxxxx> wrote:
I suspect that you are preparing a reroll already, but the one that
is sitting in 'pu' seems to be flaky in t/t0021 and I seem to see
occasional failures from it.
I didn't trace where the test goes wrong, but one easy mistake you
could make (I am not saying that is the reason of the failure) is to
assume your filter will not be called under certain condition (like
immediately after you checked out from the index to the working
tree), when the automated test goes fast enough and get you into a
"racy git" situation---the filter may be asked to filter the
contents from the working tree again to re-validate what's there is
still what is in the index.
Thanks for the heads-up!
This is what happens:
1) Git exits
2) The filter process receives EOF and prints "STOP" to the log
3) t0021 checks the content of the log
Sometimes 3 happened before 2 which makes the test fail.
(Example: https://travis-ci.org/git/git/jobs/162660563 )
I added a this to wait until the filter process terminates:
+wait_for_filter_termination () {
+ while ps | grep -v grep | grep -F "/t0021/rot13-filter.pl" >/dev/null 2>&1
+ do
+ echo "Waiting for /t0021/rot13-filter.pl to finish..."
+ sleep 1
+ done
+}
Does this look OK to you?
Do we need the ps at all ?
How about this:
+wait_for_filter_termination () {
+ while ! grep "STOP" LOGFILENAME >/dev/null
+ do
+ echo "Waiting for /t0021/rot13-filter.pl to finish..."
+ sleep 1
+ done
+}