On Wed, Jul 9, 2025 at 9:13 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 7/8/2025 5:43 PM, Elijah Newren wrote: > > On Tue, Jul 8, 2025 at 4:20 AM Derrick Stolee via GitGitGadget > > <gitgitgadget@xxxxxxxxx> wrote: > >> [...] > >> Add a new subcommand to 'git sparse-checkout' that removes these > >> tracked-but-sparse directories, including any excluded or ignored files > >> underneath. > > > > "including"? > > Yes. If we leave the ignored files then we have not accomplished our > goal in deleting the sparse directories. I understood that; my interest was more in what is being glossed over with this word, i.e. what else would be removed. > >> This is the most extreme method for doing this, but it works > >> when the sparse-checkout is in cone mode and is expected to rescope > >> based on directories, not files. > > > > So is this also meant for cone mode without sparse index turned on? > > What about non-cone mode? > > This command die()s if not in cone mode. We can consider future > changes that perform similar actions in non-cone mode, but I'm > not sure if there is a valuable need in that case. That answers the second question; what about the first -- cone mode without a sparse index? (Edit: you discuss that below, so I'll add more there.) > >> Be sure to add a --dry-run option so users can predict what will be > >> deleted. In general, output the directories that are being removed so > >> users can know what was removed. > > > > Is greater fidelity of interest when there are multiple different > > types of files contained? For example, "git status" lists individual > > files within a directory, unless it find an ignored directory and then > > it simply lists the directory. That means we get more fidelity when > > it's warranted, and less when it's not. I'm not sure if that's a > > perfect analogy, though; it may well be that we don't need the same > > kind of fidelity that `git status` provides. (And I'm kind of > > guessing it isn't needed, except in error cases, but I'm just asking.) > > > >> Note that untracked directories remain. > > > > What does this mean? If the sparse directory had an untracked > > directory within it then it'll be left on disk, you will only clean up > > untracked files at a depth of 1 within the sparse directory? > > > > Or that untracked directories not contained within a sparse directory > > will be left alone? > > This second part: "untracked directories not contained within > a sparse directory will remain". This is mostly to point out > that we are not saying "the only directories that remain are > tracked directories within the sparse-checkout" as that could > remove valuable temporary directories that are covered by > .gitignore or exclude files. Thanks; could this be clarified in the commit message? > >> Further, directories that > >> contain staged changes are not deleted. > > > > Shouldn't those be safe to delete? When a sparse directory has files > > underneath it with staged changes, those roll-up into a staged > > sparse-directory tree value, and so we should be able to delete the > > file. > > This is _mostly_ an implementation detail. The sparse index will > not represent this directory as a sparse directory, so it's not > deleted. (see the next paragraph:) If there are files with staged changes underneath a directory, I don't see why the sparse index would not be able to represent that directory as a sparse directory.
