From: Junio C Hamano Date: Thu, 18 Nov 2021 22:13:17 GMT Subject: Re: [PATCH 0/2] Sparse index: fetch, pull, ls-files Message-ID: In-Reply-To: <08679a6f-51c1-0e48-9dcc-e7ac4c9a9c80@gmail.com> Derrick Stolee 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.