On Tue, Nov 15, 2022 at 7:18 PM ZheNing Hu <adlternative@xxxxxxxxx> wrote: > ZheNing Hu <adlternative@xxxxxxxxx> 于2022年11月15日周二 12:03写道： > > Elijah Newren via GitGitGadget <gitgitgadget@xxxxxxxxx> 于2022年11月6日周日 14:04写道： [...] > > > +sparse specification: The set of paths in the user's area of focus. This > > > + is typically just the tracked files that match the sparsity > > > + patterns, but the sparse specification can temporarily differ and > > > + include additional files. (See also "Sparse specification > > > + vs. sparsity patterns") > > > + > > > + * When working with history, the sparse specification is exactly > > > + the set of files matching the sparsity patterns. > > > + * When interacting with the working tree, the sparse specification > > > + is the set of tracked files with a clear SKIP_WORKTREE bit or > > > + tracked files present in the working copy. > > > > I found af6a518 (repo_read_index: clear SKIP_WORKTREE bit from files > present in worktree) Yes, that was one of the footnotes referenced in the file: +[3] (Present-despite-skipped entries) + https://lore.kernel.org/git/11d46a399d26c913787b704d2b7169cafc28d639.1642175983.git.gitgitgadget@xxxxxxxxx/ > which maybe a good place to learn about "sparse specification", > it has a long commit message though. Not quite; it was a predecessor that described some of the bugs caused by the facts that: * "SKIP_WORKTREE" meant the file would be missing from the worktree * the above promise was often violated in a variety of ways Experience with all the bugs caused by this situation (and the many other attempted workarounds we tried that kept falling short) certainly informed my suggestions about the sparse specification. However, that only looks at the working tree side; the sparse specification is also expanded for index-related operations, as I called out in the other email I just sent you.
