Re: [PATCH] perf: work around the tested repo having an index.lock

On Mon, Jun 5, 2017 at 4:02 AM, Junio C Hamano wrote: > Christian Couder writes: > >> On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano wrote: >>> Ævar Arnfjörð Bjarmason writes: >>> > My feeling exactly.

Re: [PATCH] perf: work around the tested repo having an index.lock

Jeff King writes: > I don't really mind addressing this one case that much. I'm not sure > that we want to accrue a pile of band-aids here that causes a > maintenance burden and doesn't really solve the problem completely. One > way to do that is to say no to the first band-aid.

Re: [PATCH] perf: work around the tested repo having an index.lock

Christian Couder writes: > On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason writes: >> My feeling exactly. Diagnosing and failing upfront saying "well you made a copy but it is not

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sun, Jun 04, 2017 at 11:04:50AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > But I think a more compelling case is that there may be an ongoing > > operation in the original repo (e.g., say you are in the middle of > > writing a commit message) when we do a blind

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sun, Jun 04, 2017 at 09:00:28AM +0900, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > >> My feeling exactly. Diagnosing and failing upfront saying "well you > >> made a copy but it is not suitable for testing" sounds more sensible > >> at lesat to me. > > > >

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sun, Jun 04, 2017 at 09:55:15AM +0200, Ævar Arnfjörð Bjarmason wrote: > > Is a local clone really much slower these days? Wouldn't it is use > > hard links too? > > By the way the many properties that are preserved might not be worth > > preserving as they could make results depend a lot on

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sun, Jun 4, 2017 at 9:37 AM, Christian Couder wrote: > On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason writes: >> My feeling exactly. Diagnosing and failing upfront saying "well you

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >>> My feeling exactly. Diagnosing and failing upfront saying "well you >>> made a copy but it is not suitable for testing" sounds more sensible >>> at lesat to me. >>

Re: [PATCH] perf: work around the tested repo having an index.lock

Jeff King writes: > But I think a more compelling case is that there may be an ongoing > operation in the original repo (e.g., say you are in the middle of > writing a commit message) when we do a blind copy of the filesystem > contents. You might racily pick up a lockfile. > >

Re: [PATCH] perf: work around the tested repo having an index.lock

Junio C Hamano writes: > Perhaps run "fsck" and "status" immediately after copying to make > sure they succeed, or something like that? Hmph, this is me half-being silly, as this "copying an existing one" is meant for testing Git with a large repository, and having to run

Re: [PATCH] perf: work around the tested repo having an index.lock

Ævar Arnfjörð Bjarmason writes: >> My feeling exactly. Diagnosing and failing upfront saying "well you >> made a copy but it is not suitable for testing" sounds more sensible >> at lesat to me. > > This change makes the repo suitable for testing when it wasn't before. Perhaps

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sat, Jun 3, 2017 at 1:52 AM, Junio C Hamano wrote: > Jeff King writes: > >> But I think a more compelling case is that there may be an ongoing >> operation in the original repo (e.g., say you are in the middle of >> writing a commit message) when we do a

Re: [PATCH] perf: work around the tested repo having an index.lock

Jeff King writes: > But I think a more compelling case is that there may be an ongoing > operation in the original repo (e.g., say you are in the middle of > writing a commit message) when we do a blind copy of the filesystem > contents. You might racily pick up a lockfile. > >

Re: [PATCH] perf: work around the tested repo having an index.lock

On Fri, Jun 2, 2017 at 8:45 PM, Jeff King wrote: > On Fri, Jun 02, 2017 at 10:33:30AM +, Ævar Arnfjörð Bjarmason wrote: > >> When the tested repo has an index.lock file it should be removed. This >> file may be present if e.g. git-status previously crashed in that >> repo, and

Re: [PATCH] perf: work around the tested repo having an index.lock

On Fri, Jun 02, 2017 at 10:33:30AM +, Ævar Arnfjörð Bjarmason wrote: > When the tested repo has an index.lock file it should be removed. This > file may be present if e.g. git-status previously crashed in that > repo, and it will make a lot of git commands fail. Let's try harder > and remove