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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 5, 2017, 02:02 UTC
Message-ID: <xmqqa85nur85.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAP8UFD1u-C-T2X+H8WxxB7O+ajcGfygRBLN0t7+zJcOh_SrvFQ@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

Show 20 quoted lines

> On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano <gitster@pobox.com> 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.
>
> If we don't like git-unaware copies, maybe we should go back to the
> reasons why we are making one here.

We do need git-unaware bit-for-bit copy for testing, because you may want to see the effect of unreachable objects, for example.

It's just that git-unaware copies, because it cannot be an atomic snapshot, can introduce inconsistencies the original repository did not have, rendering the result ineffective.