Re: [PATCH 0/2] Sparse index: fetch, pull, ls-files

[Junio C Hamano <gitster@pobox.com>]

Derrick Stolee <stolee@gmail.com> writes:

>> But what makes sure, after all of the above happens, that no new
>> changes that assume it can walk the full index enters in the
>> codebase?
>> 
>> In other words, after "fetch" is declared "sparse clean" with patch
>> [1/2], what effort from us will it take to stay clean?
>
> The tests in t1092 that use the "ensure_not_expanded" helper are
> intended to be regression tests that would start failing if the
> sparse index starts expanding in a new way. I think this is what
> you mean by staying "sparse clean".

It is more like how would we help a new piece of code, which does
not even consider the possibility that the in-core index might be
sparse, and instead blindly walks the in-core index entries, doing
something unexpected (to both the author of the new code and to
those who are aware of the sparse-index feature) when it sees an
"tree" entry.  We'll hopefully see a breakage and the developer who
added such a new piece of code can keep both halves?

> One direction I could see is that as new features are contributed
> that change how the index is used, these features are not
> automatically tested with sparse-checkout and the sparse index.
> In this case, we will need to increase our awareness when reviewing
> such features to ensure that they could fit within the sparse index
> model (or are sufficiently protected by ensure_full_index() in their
> first version).

Yup, making developers aware of the issue is probably the good first
thing to do.