Re: [PATCH v4 00/10] Sparse index: delete ignored files outside sparse cone

[Derrick Stolee <stolee@gmail.com>]

On 8/27/2021 6:01 PM, Elijah Newren wrote:
> Sorry, one more thing...
> 
> On Fri, Aug 27, 2021 at 2:56 PM Elijah Newren <newren@gmail.com> wrote:
>>
>> On Tue, Aug 24, 2021 at 2:51 PM Derrick Stolee via GitGitGadget
>> <gitgitgadget@gmail.com> wrote:
> 
>>>   8:  febef675f05 !  9:  c19d93ec5d7 sparse-checkout: clear tracked sparse dirs
>>>      @@ Commit message
>>>           the sparse directory. This depends on the indexed version of the file,
>>>           so the sparse directory must be expanded.
>>>
>>>      +    We must take special care to look for untracked, non-ignored files in
>>>      +    these directories before deleting them. We do not want to delete any
>>>      +    meaningful work that the users were doing in those directories and
>>>      +    perhaps forgot to add and commit before switching sparse-checkout
>>>      +    definitions. Since those untracked files might be code files that
>>>      +    generated ignored build output, also do not delete any ignored files
>>>      +    from these directories in that case. The users can recover their state
>>>      +    by resetting their sparse-checkout definition to include that directory
>>>      +    and continue. Alternatively, they can see the warning that is presented
>>>      +    and delete the directory themselves to regain the performance they
>>>      +    expect.
> 
> Will deleting the directory regain the performance they expect, or is
> another step needed?  In other worse, will the sparsification of the
> paths under the no-longer-needed directory into a sparse directory
> entry just happen automatically as part of some other command like
> commit/add, or do they need to manually run `git sparse-checkout
> reapply`?

If the directory is gone, then their performance returns to as they
expect, since the next Git command will not need to expand the index
to detect the difference between tracked, untracked, and ignored files
within the sparse directory.

(Recall that the index is stored as sparse even if it expands to a
full one in-memory during execution.)

Thanks,
-Stolee