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

From: Jeff King <peff@peff.net>
Date: Jun 4, 2017, 08:29 UTC
Message-ID: <20170604082919.y5g34udvyjfaqtve@sigill.intra.peff.net>
In-Reply-To: <xmqqefv0wrj7.fsf@gitster.mtv.corp.google.com>

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

Show 16 quoted lines

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