Re: [RFC PATCH v2 3/4] grep: honor sparse checkout patterns
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Jun 10, 2020, 17:42 UTC
- Message-ID
- <909e19aa-9d96-a68a-eed0-d721948b9dbc@gmail.com>
- In-Reply-To
- <CAHd-oW7BXWzaWsvsh0dQt7NgeBcz0HSbcwKVYA7sPjUinarsng@mail.gmail.com>
On 6/10/2020 12:22 PM, Matheus Tavares Bernardino wrote:
Show 23 quoted lines
> On Wed, Jun 10, 2020 at 8:41 AM Derrick Stolee <stolee@gmail.com> 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@mail.gmail.com/
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