git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Elijah Newren <newren@gmail.com>
Date
Jan 31, 2020, 19:59 UTC
Message-ID
<CABPp-BHNxGFFgMMABto0y0LA6xxqqDEcVGw4FSN=1JdH53+V9Q@mail.gmail.com>
In-Reply-To
<ef39f8c5-ce0b-a48b-940d-821df563b292@gmail.com>
On Thu, Jan 30, 2020 at 10:52 AM Derrick Stolee <stolee@gmail.com> wrote:
Show 31 quoted lines
> 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.

Show 6 quoted lines
> 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
Previous: Finn Bryant
Message 5 of 5 in “Sparse checkout inconsistency with non-folder paths between cone mode and full matching (2.5.0)”
  1. Finn BryantJan 30, 2020
  2. Derrick StoleeJan 30, 2020
  3. Derrick StoleeJan 30, 2020
  4. Finn BryantJan 31, 2020
  5. Elijah NewrenJan 31, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.