Re: bug report: git checkout deletes worktree file even though it is excluded by sparse-checkout

[Derrick Stolee <stolee@gmail.com>]

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