On Mon, Aug 30, 2021 at 6:34 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 8/27/2021 6:01 PM, Elijah Newren wrote: > > Sorry, one more thing... > > > > On Fri, Aug 27, 2021 at 2:56 PM Elijah Newren <newren@xxxxxxxxx> wrote: > >> > >> On Tue, Aug 24, 2021 at 2:51 PM Derrick Stolee via GitGitGadget > >> <gitgitgadget@xxxxxxxxx> wrote: > > > >>> 8: febef675f05 ! 9: c19d93ec5d7 sparse-checkout: clear tracked sparse dirs > >>> @@ Commit message > >>> the sparse directory. This depends on the indexed version of the file, > >>> so the sparse directory must be expanded. > >>> > >>> + We must take special care to look for untracked, non-ignored files in > >>> + these directories before deleting them. We do not want to delete any > >>> + meaningful work that the users were doing in those directories and > >>> + perhaps forgot to add and commit before switching sparse-checkout > >>> + definitions. Since those untracked files might be code files that > >>> + generated ignored build output, also do not delete any ignored files > >>> + from these directories in that case. The users can recover their state > >>> + by resetting their sparse-checkout definition to include that directory > >>> + and continue. Alternatively, they can see the warning that is presented > >>> + and delete the directory themselves to regain the performance they > >>> + expect. > > > > Will deleting the directory regain the performance they expect, or is > > another step needed? In other worse, will the sparsification of the > > paths under the no-longer-needed directory into a sparse directory > > entry just happen automatically as part of some other command like > > commit/add, or do they need to manually run `git sparse-checkout > > reapply`? > > If the directory is gone, then their performance returns to as they > expect, since the next Git command will not need to expand the index > to detect the difference between tracked, untracked, and ignored files > within the sparse directory. > > (Recall that the index is stored as sparse even if it expands to a > full one in-memory during execution.) Right, as with the other email, this was the piece that hadn't quite stuck or registered for me. Thanks for clarifying.
