Hello, this originally occurred with Git for Windows (see https://github.com/git-for-windows/git/issues/3411) but it appears the underlying issue is within Git itself, see Johannes Schindelin's comment (https://github.com/git-for-windows/git/issues/3411#issuecomment-914188040). ## Description When Git fails to check out files (during `git clone`) the index seems to be in an incomplete state afterwards. The files which could not be checked out are erroneously staged as "deleted", and files which were checked out successfully are marked as untracked. This renders the suggested `git restore --source=HEAD :/` command to retry the checkout ineffective. ## Reproduction steps (Windows) Preconditions: - Long Windows file paths are not enabled (https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd#enable-long-paths-in-windows-10-version-1607-and-later) - `git config core.longpaths` is not set 1. `git clone https://github.com/dependabot/dependabot-core --depth=1 file-name-test` (should fail due to too long file names) 2. `cd file-name-test` 3. `git status` (should claim that files for which checkout failed are staged as "deleted") 4. `git config core.longpaths true` 5. Run the command suggested by the error message from step 1: `git restore --source=HEAD :/` 6. `git status` (you should see that `git restore` had no effect) ## System information Microsoft Windows [Version 10.0.19043.1237] git version 2.33.0.windows.2 All reproduction steps up to, including, step 3 can also be reproduced with WSL 2. You might need to use a different Git repository with longer files names though, such as https://github.com/Marcono1234/git-file-length-test WSL 2: 5.4.72-microsoft-standard-WSL2 git version 2.25.1
