On Mon, Jun 5, 2017 at 4:02 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Christian Couder <christian.couder@xxxxxxxxx> writes: > >> On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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. I think there might be different kind of people interested in performance tests. Users with existing repositories might want to see how the different Git versions perform on their real life repos. Developers might want to test Git on different repos with different characteristics. For example some developers might want to test on repos with and without a lot of unreachable objects, to make sure that the latest changes they made improve perf in both cases. While some users might only be interested in testing on their actual repositories to see how the latest Git versions improve things (or not) in practice. In this example the needs of developers would perhaps be better suited if they could control the amount of unreachable objects in the tests, while the needs of the users would be better suited if the tests just used actual repos as is. So I wonder what changes would be needed to the perf framework and the perf tests to accomodate both of these kinds of needs. > 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.