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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 18, 2021, 22:13 UTC
Message-ID: <xmqqfsrtw1s2.fsf@gitster.g>
In-Reply-To: <08679a6f-51c1-0e48-9dcc-e7ac4c9a9c80@gmail.com>

Derrick Stolee <stolee@gmail.com> writes:

Show 11 quoted lines

>> 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?

Show 7 quoted lines

> 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.