Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 20, 2017 at 06:42:59PM +0200, SZEDER Gábor wrote: > > I suppose so. It might be worth being picky just on the principle that > > if it _is_ gone that's unexpected and we'd prefer somebody notice and > > figure out why. > > OK, agreed. > > However, we do need the above 'test -d' for

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Fri, Apr 14, 2017 at 10:08 PM, Jeff King wrote: > On Thu, Apr 13, 2017 at 09:35:08PM +0200, SZEDER Gábor wrote: > >> >> diff --git a/t/test-lib.sh b/t/test-lib.sh >> >> index 13b569682..d7fa15a69 100644 >> >> --- a/t/test-lib.sh >> >> +++ b/t/test-lib.sh >> >> @@ -763,7 +763,7

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 09:35:08PM +0200, SZEDER Gábor wrote: > >> diff --git a/t/test-lib.sh b/t/test-lib.sh > >> index 13b569682..d7fa15a69 100644 > >> --- a/t/test-lib.sh > >> +++ b/t/test-lib.sh > >> @@ -763,7 +763,7 @@ test_done () { > >> > >> test -d "$remove_trash" && > >

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 9:12 PM, Jeff King wrote: > On Thu, Apr 13, 2017 at 09:03:26PM +0200, SZEDER Gábor wrote: > >> > Yeah, I had a similar thought. I can't think of any reason why it would >> > trigger a false positive, as long as we account for test-failure and the >> >

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 09:03:26PM +0200, SZEDER Gábor wrote: > > Yeah, I had a similar thought. I can't think of any reason why it would > > trigger a false positive, as long as we account for test-failure and the > > --debug flag properly. I don't think we can just drop the "-f" from the > >

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 7:57 PM, Jeff King wrote: > On Thu, Apr 13, 2017 at 10:55:08AM -0700, Stefan Beller wrote: > >> On Thu, Apr 13, 2017 at 9:37 AM, Jeff King wrote: >> > Ah, OK, that makes more sense. I can detect it reliably by just checking >> > >> > ! test

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 10:55:08AM -0700, Stefan Beller wrote: > On Thu, Apr 13, 2017 at 9:37 AM, Jeff King wrote: > > Ah, OK, that makes more sense. I can detect it reliably by just checking > > > > ! test -d $root/trash* > > > > in my stress-test after the test successfully

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 9:37 AM, Jeff King wrote: > Ah, OK, that makes more sense. I can detect it reliably by just checking > > ! test -d $root/trash* > > in my stress-test after the test successfully completes. Would we want to report such an error from the test suite itself?

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 12:03:20AM +0200, SZEDER Gábor wrote: > > I couldn't get the original to show a failure, though, even under heavy > > load. So maybe widening the race is enough. > > Just to be clear: it's only an occasionally appearing error message. > There is no failure in the sense of

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Wed, Apr 12, 2017 at 2:50 AM, Jeff King wrote: > On Wed, Apr 12, 2017 at 02:27:05AM +0200, SZEDER Gábor wrote: > >> >> I wonder if you could make it a general test-lib function, like: >> >> >> >> run_and_wait () { >> >> # we read stdout from the child only for the side

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Wed, Apr 12, 2017 at 02:27:05AM +0200, SZEDER Gábor wrote: > >> I wonder if you could make it a general test-lib function, like: > >> > >> run_and_wait () { > >> # we read stdout from the child only for the side effect > >> # of waiting until all child sub-processes exit,

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Tue, Apr 11, 2017 at 11:32 PM, Johannes Sixt wrote: > Am 10.04.2017 um 19:01 schrieb Jeff King: >> >> I wonder if you could make it a general test-lib function, like: >> >> run_and_wait () { >> # we read stdout from the child only for the side effect >> # of

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

Am 10.04.2017 um 19:01 schrieb Jeff King: I wonder if you could make it a general test-lib function, like: run_and_wait () { # we read stdout from the child only for the side effect # of waiting until all child sub-processes exit, closing their # fd 9.

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Mon, Apr 10, 2017 at 06:56:30PM +0200, SZEDER Gábor wrote: > On Mon, Apr 10, 2017 at 6:35 PM, Jeff King wrote: > > On Mon, Apr 10, 2017 at 06:31:54PM +0200, SZEDER Gábor wrote: > > >> This means we can write this simply as: > >> > >> doesnt_matter=$(git gc --auto 9>&1) > >>

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Mon, Apr 10, 2017 at 6:35 PM, Jeff King wrote: > On Mon, Apr 10, 2017 at 06:31:54PM +0200, SZEDER Gábor wrote: >> This means we can write this simply as: >> >> doesnt_matter=$(git gc --auto 9>&1) >> >> It's still hackery :) > > Heh. Yeah, I would call that _more_ hackery in

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Mon, Apr 10, 2017 at 06:31:54PM +0200, SZEDER Gábor wrote: > Indeed this seems to work, and luckily we don't need that much > hackery. When there is a single variable assignment and the expansion > of a command substitution is assigned to the variable, then the exit > status is that of the

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Mon, Apr 10, 2017 at 3:58 PM, Jeff King wrote: > On Mon, Apr 10, 2017 at 02:59:11PM +0200, SZEDER Gábor wrote: > >> While this change doesn't completely eliminate the possibility of >> this race, it significantly and seemingly sufficiently reduces its >> probability. Running

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Mon, Apr 10, 2017 at 02:59:11PM +0200, SZEDER Gábor wrote: > While this change doesn't completely eliminate the possibility of > this race, it significantly and seemingly sufficiently reduces its > probability. Running t6500 in a loop while my box was under heavy CPU > and I/O load usually