Re: [PATCH v4 00/10] Sparse index: delete ignored files outside sparse cone
flat view
From: Elijah Newren <hidden>
Date: 2021-08-30 20:23:57
On Mon, Aug 30, 2021 at 6:54 AM Derrick Stolee [off-list ref] wrote:
On 8/27/2021 5:56 PM, Elijah Newren wrote:quoted
On Tue, Aug 24, 2021 at 2:51 PM Derrick Stolee via GitGitGadget [off-list ref] wrote:quoted
...
quoted
quoted
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. +...quoted
quoted
++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....quoted
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.