Re: [PATCH v2 0/8] sparse-checkout: add 'clean' command

[Junio C Hamano <gitster@pobox.com>]

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

> This command uses the same '--force' and '--dry-run' options as 'git clean',
> with integrations with the 'clean.requireForce' config option. There are
> some concerns that this isn't an obvious way to work with the 'git clean'
> command, but I thought we should be consistent here. I did change the error
> message to point users to the necessary options.
>
> This option would be preferred to something like 'git clean -dfx' since it
> does not clear the excluded files that are still within the sparse-checkout.
> Instead, it performs the exact filesystem operations required to refresh the
> sparse index performance back to what is expected.
>
> I spent a few weeks debating with myself about whether or not this was the
> right interface, so please suggest alternatives if you have better ideas.
> Among my rejected ideas include:
>
>  * 'git sparse-checkout reapply -f -x' or similar augmentations of
>    'reapply'.
>  * 'git clean --sparse' to focus the clean operation on things outside of
>    the sparse-checkout.
>
>
> Updates in V2
> =============
>
>  * This series is based on 2c5b5565981 (environment: remove the global
>    variable 'sparse_expect_files_outside_of_patterns', 2025-07-01) to build
>    upon those cleanups in builtin/sparse-checkout.c.
>  * The --force and --dry-run options match 'git clean'.
>  * A --verbose option is added. It does not link to the index for
>    tracked/untracked/ignored/excluded or clean/modified/staged/conflicted
>    status, but instead gives the full list for information.
>  * To support the --verbose option, a new for_each_file_in_dir() method is
>    added to dir.h.
>  * Tests are added to demonstrate the behavior when a sparse directory has a
>    merge conflict (fails with an explanation). When adding the test based on
>    the previous version's functionality, I realized that the behavior is
>    sometimes less effective than git sparse-checkout reapply even after a
>    sparse file is committed. To demonstrate this change, the full test is
>    created on its own and then a code change is added with the impact on the
>    test.

This seems to have a few comments that haven't been responded to
(plus a "This step looks good to me" or two).  Can we get it unstuck
soonish?  The topic is from mid July and I do not like to hold topics
in 'seen' for longer than a month without any activity.

Thanks.