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. > I'm also worried that making a config option may have masked subtle > bugs in the patch that the rest of the testsuite would have turned up. 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
