From: Derrick Stolee Date: Thu, 11 Sep 2025 13:52:30 GMT Subject: Re: [PATCH v2 3/8] sparse-checkout: match some 'clean' behavior Message-ID: <4ed3dd55-6eba-4cce-ba00-626f4d9cddab@gmail.com> In-Reply-To: On 8/5/25 6:06 PM, Elijah Newren wrote: > On Wed, Jul 16, 2025 at 6:34 PM Derrick Stolee via GitGitGadget > wrote: >> >> From: Derrick Stolee >> >> 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