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

[Christian Couder <christian.couder@gmail.com>]

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.
In 342e9ef2d9 (Introduce a performance testing framework, 2012-02-17),
Thomas wrote:

    3. Creating test repos from scratch in every test is extremely
       time-consuming, and shipping or downloading such large/weird repos
       is out of the question.

       We leave this decision to the user.  Two different sizes of test
       repos can be configured, and the scripts just copy one or more of
       those (using hardlinks for the object store).  By default it tries
       to use the build tree's git.git repository.

       This is fairly fast and versatile.  Using a copy instead of a clone
       preserves many properties that the user may want to test for, such
       as lots of loose objects, unpacked refs, etc.

Is a local clone really much slower these days? Wouldn't it is use
hard links too?
By the way the many properties that are preserved might not be worth
preserving as they could make results depend a lot on the current
state of the original repo.