Hi all
Thanks for the reviews and comments.
My use case is that I never want it to remove or otherwise touch those files outside of sparse-checkout that happen to be the same path as index paths. I realize that currently gives me complications (e.g. I must never try and merge/cherry-pick/rebase a commit that might cause a merge conflict out there), and I realize that’s not what everyone else wants. For example, I don’t want git reset --hard or whatever to remove those files. Hence the config option.
Am I right in saying that the sparse-index work makes it easier to achieve my use case? In that those outside-sparse-checkout paths would not ever get merged into the index, even if I merge/cherry-pick/rebase a tree with paths there?
I can go into more details on how I arrived ay my use case if it helps.
So maybe there are two separate things here:
1. The bug that checkout removes my file when it is dirty, instead of refusing (unless -f) or just ignoring it.
2. My use case, which is to do its best to never remove or otherwise touch worktree files outside sparse-checkout.
It is true that not hiding it in a config option makes a few tests fail, including ones that specifically test that a git reset after a materialization from a merge conflict causes the file to be removed.
Thanks.
-tpr