On 5/28/2021 4:14 PM, Tim Renouf (open source) wrote: > Hi all > > I have a bug report: git checkout deletes a worktree file even though it is excluded by sparse-checkout, even if it is dirty. ... > I set up sparse-checkout to include only file1, not file2. file2 is now not in the worktree, even though it is in the commit I am checked out at. Then I create file2 with arbitrary content. Then a git checkout switching to the commit where file2 is removed also deletes it from the worktree. > > I assert that file2 should be left untouched by that checkout, because it is excluded by sparse-checkout. I guess file2 had its skip-worktree bit set before the checkout that removed it from the index; that should stop it being deleted in the worktree. In this case, 'file2' exists in the index at 'master' and 'git checkout master' made the working directory appear as if it was at that position with the sparse-checkout patterns applied. The confusion happens that Git behaves differently when a file exists outside the sparse-checkout patterns based on whether the file actually exists in the index or not. Only an exact path match with a sparse index entry will cause this deletion. This is another reason why I prefer the "cone mode" patterns: it is harder to get this kind of problem. You could easily make it happen with "folder2/file" where "folder2" is not in the cone mode sparse-checkout, but it's less likely in some way. > To be clear, I expect that last “ls” to still show “file1 file2”. I can understand this expectation. I don't think that if we changed this behavior that it would cause any confusion. That is, as long as the file disappears when no longer dirty, _and_ a command such as "git reset --hard" overwrites the file. It is important to provide ways for users to remove the file when they want it gone. Thanks, -Stolee
