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

[Jeff King <peff@peff.net>]

On Sun, Jun 04, 2017 at 09:00:28AM +0900, Junio C Hamano wrote:

> Æ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.

Right. What I was getting at in my original message was that this is the
tip of the iceberg if we are worried about inconsistent states. And the
right solution is probably to say "you are on your own for making sure
the repo you point to is in a sane state". Because there are so many
cases to catch, and they're so rare, it's not worth trying to catch them
all.

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. But we could also
apply it and see what happens. At the very worst it's a few extra lines
of code, and we can start to get worried on the second or third
band-aid.

-Peff