Re: Sparse checkout inconsistency with non-folder paths between cone mode and full matching (2.5.0)

[Elijah Newren <newren@gmail.com>]

On Thu, Jan 30, 2020 at 10:52 AM Derrick Stolee <stolee@gmail.com> 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