Re: [RFC PATCH v2 3/4] grep: honor sparse checkout patterns

On 6/10/2020 12:22 PM, Matheus Tavares Bernardino wrote:

On Wed, Jun 10, 2020 at 8:41 AM Derrick Stolee [off-list ref] wrote:

quoted

On 5/22/2020 10:26 AM, Elijah Newren wrote:

quoted

+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@mail.gmail.com/ (local)

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".

If we revert that part of my change to use `grep` instead
of `git grep`, then is my statement correct?

Thanks,
-Stolee