On Thu, Jan 30, 2020 at 10:52 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > Practical: How do we specify if an input is a directory or a file? > > As you mentioned, if you run "git sparse-checkout set X" then you get > a sparse-checkout file containing: > > /* > !/*/ > /X/ > > But if X is actually a _file_, then we should write this pattern: > > /* > !/*/ > /X > > So the input does not provide enough information to say which pattern > should be written. > > The other concern about this second set of patterns is that "/X" is > only a _prefix_ match, not an exact path name match. That means we > cannot use the existing hashset matching to result in the same > pattern matching as non-cone-mode. > > Now, there is perhaps a way to decide between the two: inspect the > current index or tree for whether the input corresponds to a directory > or a file. This adds a layer of complexity that is not currently in > the sparse-checkout builtin, but it is not insurmountable. The only > thing to consider is what happens when the input path is not in the > index/tree at all! It may be that we want to specify the patterns > before moving HEAD to a commit that _does_ contain the path, and then > we would do the wrong thing at this point. And once people ran into the difference because their repo was weird, they'd be bewildered. I don't want to deal with those support questions; let's just disallow the latter form and require the trailing slash. There are three alternate universes we could have supported such an ability under: * If we had decided to use regexes instead of fnmatch for sparse-checkout/gitignore then we could have a /<path>$ pattern to match just files * If fnmatch had an end-of-input marker like regex's '$', then we could use it to mark exact files and be able to translate that into hashes. * If we had decided that cone mode uses an input file other than .git/info/sparse-checkout with a different format, we wouldn't have to worry about strict compatibility of the format with non-cone mode and support different types of abilities. But I think it's too late now. Let's just leave the trailing slash there and say we only support directory-based matching in cone mode. > So I'll put out a question to the community: is this practical issue > something worth overcoming? Is my concern about a non-existent path > a true problem, or something more? > > Thanks, > -Stolee
