Hi, With cone mode enabled for a sparse checkout, a pattern like the following is accepted: /* !/*/ /a_file_or_folder/ As the name suggests, a_file_or_folder might be a file, or might be a directory. If it's a directory, then this is a "valid" recursive match for the directory and everything works as expected. But if the path leads to an ordinary file, it appears that cone mode will *exclude* the file from the worktree (ie, it'll have the skip-worktree flag set). This seems bizarre and unexpected behaviour. My suspicion is that cone mode is supposed to be a pure subset of full pattern matching, such that if cone mode is ever disabled, the sparseness of the worktree will be unchanged. Clearly, this scenario is breaking that pattern. I think the correct behaviour is that recursive matches for a potential directory do not have any effect on a non-directory file with the same name. Alternatively, you could forbid any patterns which match non-directory files instead (and downgrade to full pattern matching), though I'd not be a fan of this, since it'd mean the validity of a cone-mode sparse configuration file is dependent on the contents of the repo, and is thus much harder to ascertain (scripts can't simply prove if it's a valid cone mode file by parsing it, they'd need to have access to any repo it may be applied to, and inspect the type of any matching file/folder paths, and its validity could be changed simply by replacing a folder with a file in the repo). If matching behaviour with full pattern mode is a non-goal for cone mode, I'd still question the logic of this behaviour, though I suppose it does have the benefit of (accidentally?) adding support for excluding individual files from a sparse checkout, which I imagine some could find useful. Personally I'd prefer that was instead added with a more sane syntax, if needed. Full test case: $ git init test_repo Initialized empty Git repository in [path]/test_repo/.git/ $ cd test_repo/ $ touch some_file a_file_or_folder $ git add some_file a_file_or_folder $ git commit -m "some files" [master (root-commit) 80d5918] some files 2 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 a_file_or_folder create mode 100644 some_file $ git sparse-checkout init --cone $ git read-tree -mu HEAD $ ls -1 a_file_or_folder some_file $ git sparse-checkout set a_file_or_folder $ git read-tree -mu HEAD $ ls -1 some_file $ cat .git/info/sparse-checkout /* !/*/ /a_file_or_folder/ $ Right now I'm trying to integrate cone mode with my company's existing manifest infrastructure, which doesn't differentiate between files and folders, so this is forcing me to perform a lot of repo checks to confirm we aren't accidentally excluding files we were supposed to include. Just in case you needed another example of why this behaviour is unhelpful.
