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

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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 "not suitable" was a bit too vague.

The copy you made is not in a consistent state that is good for
testing.  This change may declare that it is now in a consistent
state, but removal of a single *.lock file does not make it so.  We
do not know what other transient inconsistency the resulting copy
has; it is inherent to git-unaware copy---that is why we discouraged
and removed rsync transport after all.

> Yes, there are cases where there are other issues than index.lock
> preventing testing the repo, but I don't see why there shouldn't be a
> partial solution that solves a very common case in lieu of a perfect
> solution.

As long as the partial solution makes sure that the case it
addressed was the only breakage, I'd be happy to see that it leaves
other kinds of inconsistencies "too rare to bother fixing".  I however
feel dirty if the punting is "we won't even bother diagnosing and
assume that *.lock is the only thing we care about".

Perhaps run "fsck" and "status" immediately after copying to make
sure they succeed, or something like that?