On Wed, Jun 10, 2020 at 2:42 PM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 6/10/2020 12:22 PM, Matheus Tavares Bernardino wrote: > > On Wed, Jun 10, 2020 at 8:41 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > >> > >> On 5/22/2020 10:26 AM, Elijah Newren wrote: > >>> +This may mean that even if your sparsity patterns include or exclude > >>> +submodules, until you manually initialize or deinitialize them, commands > >>> +like grep that work on tracked files in the working copy will ignore "not > >>> +yet initialized" submodules and pay attention to "left behind" ones. > >> > >> I don't think that "left behind" is a good phrase here. It feels like > >> they've been _dropped_ instead of _persisted despite sparse-checkout > >> changes_. > >> > >> Perhaps: > >> > >> commands like `git grep` that work on tracked files in the working copy > >> will pay attention only to initialized submodules, regardless of the > >> sparse-checkout definition. > > > > Hmm, I'm a little confused by the "regardless of the sparse-checkout > > definition". The plan we discussed for grep was to not recurse into > > submodules if they have the SKIP_WORKTREE bit set [1], wasn't it? > > > > [1]: https://lore.kernel.org/git/CABPp-BE6M9ATDYuQh8f_r3S00dM2Cv9vM3T5j5W_odbVzhC-5A@xxxxxxxxxxxxxx/ > > Thanks for correcting my misunderstanding. By introducing > `git grep` into this documentation, I have also made it > co-dependent on your series. Instead, Elijah was probably > purposeful in his use of "grep" over "git grep". I think he used grep referring to git-grep as he mentioned "tracked files in the working copy". Maybe he wanted to describe the current state of git-grep, which does recurse into initialized submodules even when they don't match the sparsity patterns. Was that it, Elijah? If so, since this behavior is changed in mt/grep-sparse-checkout, I think I should also change this doc section within my series. Or we change the doc in this patch and make it dependent on the series.
