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.
On 28 Sep 2016, at 23:49, Junio C Hamano [off-list ref] 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?
- Lars
On 29/09/16 12:28, Lars Schneider wrote:
quoted
On 28 Sep 2016, at 23:49, Junio C Hamano [off-list ref] 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
+}
W dniu 29.09.2016 o 13:57, Torsten Bögershausen pisze:
On 29/09/16 12:28, Lars Schneider wrote:
quoted
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
+}
Or even better: make filter driver write its pid to pidfile, and then
"wait $(cat rot13-filter.pid)". That's what we do in lib-git-daemon.sh
(I think).
If the problem is exit status of "wait" builtin, then filter driver
can remove its pidfile after writing "STOP", just before ending.
--
Jakub Narębski