On 8/5/25 6:06 PM, Elijah Newren wrote:
On Wed, Jul 16, 2025 at 6:34 PM Derrick Stolee via GitGitGadget
<gitgitgadget@xxxxxxxxx> wrote:
From: Derrick Stolee <stolee@xxxxxxxxx>
The 'git sparse-checkout clean' subcommand is somewhat similar to 'git
clean' in that it will delete files that should not be in the worktree.
The big difference is that it focuses on the directories that should not
be in the worktree due to cone-mode sparse-checkout. It also does not
discriminate in the kinds of files and focuses on deleting entire
directories.
However, there are some restrictions that would be good to bring over
from 'git clean', specifically how it refuses to do anything without the
'-f'/'--force' or '-n'/'--dry-run' arguments. The 'clean.requireForce'
config can be set to 'false' to imply '--force'.
Add this behavior to avoid accidental deletion of files that cannot be
recovered from Git.
I'm a bit surprised by this. Given that the only kinds of files that
this command cleans out are untracked and ignored files, and Junio's
comments about clean.requireForce over in
https://lore.kernel.org/git/xmqqv7o2togi.fsf@gitster.g/, I thought his
comments could be interpreted as not wanting clean.requireForce to
apply in more places. Did I misunderstand?
Alternatively, maybe you thought that there were files other than
untracked and ignored which `sparse-checkout clean` would clean up,
and it was because of those files that we wanted the extra protection?
(In that case, it'd make sense, but it seems to go against what was
demonstrated in the final testcase of the previous patch.)
My thought process here was that users expect 'git clean' to be extra
careful to prevent removing files. While Junio mentioned regret in
the decision to require the '-f', I didn't want to have such a major
difference between the two commands.
I also interpreted Junio's comments to be that he wished that
clean.requireForce was 'false' by default instead of the current
assumption of 'true' if unset.
I'm open to reviewers providing a firm stance towards "the new
command should deviate closer to how we wish 'git clean' worked"
and overriding my choice to match behavior.
Thanks,
-Stolee
