Re: [PATCH v2 8/8] sparse-checkout: make 'clean' clear more files

[Derrick Stolee <stolee@gmail.com>]

On 9/11/25 11:26 AM, Derrick Stolee wrote:
> On 8/5/25 8:21 PM, Elijah Newren wrote:
>> On Wed, Jul 16, 2025 at 6:34 PM Derrick Stolee via GitGitGadget

>>>                  git sparse-checkout clean -f >out &&
>>> -               test_line_count = 0 out &&
>>> -               test_path_exists folder1/even/more/dirs/file &&
>>> -
>>> -               git sparse-checkout reapply &&
>>> -               test_path_is_missing folder1
>>> +               test_cmp expect out &&
>>> +               test_path_is_missing folder1 &&
>>> +               test_path_is_missing deep/deeper2
>>
>> Yes, but why does `git status` show folder1/even/more/dirs/file as
>> being locally deleted?  Does the code forget to update the
>> SKIP_WORKTREE status after clearing out the files?
> 
> This is an interesting quirk about how "git add --sparse <path>"
> works, which is to remove the SKIP_WORKTREE bit. It's further
> interesting that the file is still being "tracked as a deletion"
> while also being "collapsed to a sparse directory".
> 
> By expanding the earlier test cases to include these post-clean
> statuses, we can see that this change is causing this new view
> of a deleted file. I will see what I can do to determine exactly
> what's different this time and how we can minimize that
> strangeness (or: consider dropping this patch).

I'm coming to the conclusion that I should drop this patch
for now and consider this more aggressive cleaning mechanism
for a later update.

The strangest part of what's going on here is that the in-
memory sparse index collapses the folder2/ entry but an on-
disk sparse index does not in this state. That's what's
leading to this deleted entry.

I think the unpack_trees_options values are involved, but a
few experiments led to no change in my tests.

(With that, I have a v3 nearly ready, but I'll wait a day to
see if feedback on top of my comments causes me to rethink
anything.)

Thanks,
-Stolee