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
