Derrick Stolee <stolee@xxxxxxxxx> 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.
