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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 4, 2017, 00:00 UTC
Message-ID: <xmqqefv0wrj7.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACBZZX52O9Pf=5Xtq1Lg1=ZU26tm7pupvubk1ZjNJZp7kR450g@mail.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 5 quoted lines

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