On Sun, Jun 4, 2017 at 9:37 AM, Christian Couder <christian.cou...@gmail.com> wrote: > On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano <gits...@pobox.com> wrote: >> Ævar Arnfjörð Bjarmason <ava...@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.
AFAICT from some quick testing it'll hardlink the objects/ dir, so e.g. you preserve the loose objects. Making the results depend on the state of the original repo is a feature, but perhaps it should be opt in. It's very useful to be able to take a repo that's accrued e.g. a month's worth of refs & loose objects and test that v.s. a fresh clone. But there are other things that ever a hardlink local clone doesn't preserve which might be worth preserving...
