"Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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.
