Re: [PATCH v2 5/8] sparse-checkout: add --verbose option to 'clean'

[Derrick Stolee <stolee@gmail.com>]

On 8/5/25 6:22 PM, Elijah Newren wrote:
> On Wed, Jul 16, 2025 at 6:34 PM Derrick Stolee via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
>>
>> From: Derrick Stolee <stolee@gmail.com>
>>
>> The 'git sparse-checkout clean' subcommand is focused on directories,
>> deleting any tracked sparse directories to clean up the worktree and
>> make the sparse index feature work optimally.
>>
>> However, this directory-focused approach can leave users wondering why
>> those directories exist at all. In my experience, these files are left
>> over due to ignore or exclude patterns, Windows file handles, or
>> possibly merge conflict resolutions.
> 
> Seems reasonable.  And based on your previous testcases, it might not
> even be merge conflict resolutions, but just someone placing a
> (possibly-modified) copy of a tracked file back into the directory.
> 
> (I've seen folks do that, so it's not "just" your testcase doing
> something unusual.)
> 
>> Add a new '--verbose' option for users to see all the files that are
>> being deleted (with '--force') or would be deleted (with '--dry-run').
> 
> Does that answer the users' question?  You said above in your
> experience it came from a few different reasons; will users want to
> know which reason(s) for which files, or will they only want to know
> the files that are present?

I've had users asking for answers to both of these questions:

  1. What files will this remove? (I want to make sure it won't remove
     something I care about.)

  2. What files were causing my sparse index to expand? (I want to
     understand how my workflow impacts this behavior.)

> You stated in the commit message that "users wonder...why those
> directories exist at all."  Presuming that listing files is sufficient
> to answer those users questions, this patch looks good to me.  I'm
> unsure if that answers the question, or if some kind of classification
> of the files would also be wanted (ignored, untracked, conflicted,
> tracked-with-unstaged-changes, tracked-wtih-no-changes,
> tracked-with-staged-changes).  Maybe the answer is we start with this
> and wait for user feedback and only add more if there's demand, but if
> so it might be nice to state as much in the commit message.

Sounds like a plan. This verbose output is intended to be human-
readable and can easily be expanded in the future.

Thanks,
-Stolee