Re: t0027 racy?

On Thu, Aug 11, 2016 at 06:58:12PM +, Torsten Bögershausen wrote: > commit 3754404d3d1ea4a0cbbed4986cc4ac1b5fe6b66e > Author: Torsten Bögershausen > Date: Thu Aug 11 18:47:29 2016 +0200 > > t0027: Correct raciness in NNO test > > When a non-reversible CRLF

Re: t0027 racy?

Torsten Bögershausen writes: > Good ideas, I will work on a series that fixes bugs first, and then we > can see if there is room for optimization. > > What do you think about this as a starting point, more things will > follow. > I like to here comments about the commit msg first

Re: t0027 racy?

[] > FWIW I would strongly prefer to use the warning of `git add` and not even > bother with `git commit`. What we are interested in is the warning > message, generated by convert_to_git(). The commit is needed, because we check the content of the commit later. > Not using the first one and [] >

Re: t0027 racy?

Hi Torsten, On Tue, 9 Aug 2016, Torsten Bögershausen wrote: > > git -c core.autocrlf=$crlf add $fname >"${pfx}_$f.err" 2>&1 > > > > would make more sense. We _know_ that we have to do convert_to_git() in > > that step because the content is changed. And then you can ignore the > > warnings

Re: t0027 racy?

> git -c core.autocrlf=$crlf add $fname >"${pfx}_$f.err" 2>&1 > > would make more sense. We _know_ that we have to do convert_to_git() in > that step because the content is changed. And then you can ignore the > warnings from "git commit" (which are racy), or you can simply commit as > a whole

Re: t0027 racy?

On Tue, Aug 09, 2016 at 12:59:58PM +, Torsten Bögershausen wrote: > Thanks for the explanation, so there are 2 chances for a race. > > I assume that the suggested "touch" will fix race#2 in most cases. > In my understanding, the change of the file size will be more reliable: > > > diff

Re: t0027 racy?

On Tue, Aug 09, 2016 at 07:49:38AM -0400, Jeff King wrote: > On Tue, Aug 09, 2016 at 11:33:37AM +, Torsten Bögershausen wrote: > > > > The second one seems plausible, given the history of issues with > > > changing CRLF settings for an existing checkout. I'm not sure if it > > > would be

Re: t0027 racy?

On Tue, Aug 09, 2016 at 11:33:37AM +, Torsten Bögershausen wrote: > > The second one seems plausible, given the history of issues with > > changing CRLF settings for an existing checkout. I'm not sure if it > > would be feasible to reset the index completely before each tested > > command,

Re: t0027 racy?

On Tue, Aug 09, 2016 at 01:33:04PM +0200, Johannes Schindelin wrote: > On Mon, 8 Aug 2016, Jeff King wrote: > > > I got failure within about 30 seconds on t0027 (though 5 minutes? Yeesh. > > It runs in 9s on my laptop. I weep for you). > > Yep. That is the price I (and all other Git for Windows

Re: t0027 racy?

Hi Peff, On Mon, 8 Aug 2016, Jeff King wrote: > I got failure within about 30 seconds on t0027 (though 5 minutes? Yeesh. > It runs in 9s on my laptop. I weep for you). Yep. That is the price I (and all other Git for Windows developers) pay for the decision to implement Git's entire test suite

Re: t0027 racy?

On Tue, Aug 09, 2016 at 02:51:10AM -0400, Jeff King wrote: > On Mon, Aug 08, 2016 at 08:32:24PM +, Torsten Bögershausen wrote: > > > > The verbose output is not very exciting, though: > > > > > > expecting success: > > > check_warning "$lfwarn" ${pfx}_LF.err > > > > > >

Re: t0027 racy?

Hi Peff, On Tue, 9 Aug 2016, Jeff King wrote: > And indeed, this seems to fix it for me (at least it has been running in > a 16-way loop for 5 minutes, whereas before it died after 30 seconds or > so): > > diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh > index 2860d2d..9f057ff 100755

Re: t0027 racy?

Hi Torsten, On Mon, 8 Aug 2016, Torsten Bögershausen wrote: > On 2016-08-08 17.05, Johannes Schindelin wrote: > > > > I remember that you did a ton of work on t0027. Now I see problems, > > and not only that the entire script now takes a whopping 4 minutes 20 > > seconds to run on my high-end

Re: t0027 racy?

On Tue, Aug 09, 2016 at 02:51:10AM -0400, Jeff King wrote: > - index raciness causing us to avoid reading file content. For > example, if you do: > > echo foo >bar > git add bar > > Then _usually_ "bar" and the index will have the same mtime. And > therefore subsequent

Re: t0027 racy?

On Mon, Aug 08, 2016 at 08:32:24PM +, Torsten Bögershausen wrote: > > The verbose output is not very exciting, though: > > > > expecting success: > > check_warning "$lfwarn" ${pfx}_LF.err > > > > --- NNO_attr_auto_aeol_crlf_false_LF.err.expect 2016-08-08 > >

Re: t0027 racy?

On Mon, Aug 08, 2016 at 11:29:26AM -0400, Jeff King wrote: > On Mon, Aug 08, 2016 at 05:05:07PM +0200, Johannes Schindelin wrote: > > > I remember that you did a ton of work on t0027. Now I see problems, and > > not only that the entire script now takes a whopping 4 minutes 20 seconds > > to run

Re: t0027 racy?

On 2016-08-08 17.05, Johannes Schindelin wrote: > Hi Torsten, > > I remember that you did a ton of work on t0027. Now I see problems, and > not only that the entire script now takes a whopping 4 minutes 20 seconds > to run on my high-end Windows machine. > > It appears that t0027 fails randomly

Re: t0027 racy?

On Mon, Aug 08, 2016 at 05:05:07PM +0200, Johannes Schindelin wrote: > I remember that you did a ton of work on t0027. Now I see problems, and > not only that the entire script now takes a whopping 4 minutes 20 seconds > to run on my high-end Windows machine. > > It appears that t0027 fails

t0027 racy?

Hi Torsten, I remember that you did a ton of work on t0027. Now I see problems, and not only that the entire script now takes a whopping 4 minutes 20 seconds to run on my high-end Windows machine. It appears that t0027 fails randomly for me, in seemingly random places. Sometimes all 1388 cases