"Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> This is based on ld/sparse-index-blame (merged with 'master' due to an
> unrelated build issue).
>
> Here are two relatively-simple patches that further the sparse index
> integrations.
>
> Did you know that 'fetch' and 'pull' read the index? I didn't, or this would
> have been an integration much earlier in the cycle. They read the index to
> look for the .gitmodules file in case there are submodules that need to be
> fetched. Since looking for a file by name is already protected, we only need
> to disable 'command_requires_full_index' and we are done.
This reminds me of one thing. Our strategy so far has been:
- start with blindly calling ensure_full();
- audit the code and adjust each code path that needs to walk to
. keep walking the full index, but narrow the scope of
ensure_full_index() if we can; or
. stop assuming we need to walk the full index, but teach it to
"skip" the tree-in-index that we are not interested in.
- declare victory and drop the blind call to ensure_full().
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?
Thanks.
