On Mon, Aug 30, 2021 at 6:54 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 8/27/2021 5:56 PM, Elijah Newren 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. > >> + > ... > >> ++When changing the sparse-checkout patterns in cone mode, Git will inspect each > >> ++tracked directory that is not within the sparse-checkout cone to see if it > >> ++contains any untracked files. If all of those files are ignored due to the > >> ++`.gitignore` patterns, then the directory will be deleted. If any of the > >> ++untracked files within that directory is not ignored, then no deletions will > >> ++occur within that directory and a warning message will appear. If these files > >> ++are important, then reset your sparse-checkout definition so they are included, > >> ++use `git add` and `git commit` to store them, then remove any remaining files > >> ++manually to ensure Git can behave optimally. > ... > > Thanks for the extra explanations; those help. > > > > You haven't yet addressed how this choice will interact with > > .gitignore files, though (as I commented on v3). ... > The difference between the .gitattributes and .gitignore files is that > we don't need to do anything with the .gitignore files to prevent Git > from accessing them with their contained directories don't exist. The > .gitattributes change in attr.c is reachable from some code path even > when the directory doesn't exist, so it needs special logic to avoid > that expansion. Ah, this is what I was looking for and couldn't quite work out -- whether .gitignore files might need to be loaded (and whether our other UI decisions were affecting that). Sounds like you have it covered. Thanks for patiently explaining these various items I was not understanding or missing. Sorry I missed a couple key things despite reading the earlier rounds. Anyway, looks like we're in pretty good shape and there's only a few minor things left, mostly stuff you brought up yourself that you wanted to tweak for v5.
