From: Elijah Newren Date: Thu, 21 May 2020 17:52:21 GMT Subject: Re: [RFC PATCH v2 3/4] grep: honor sparse checkout patterns Message-ID: In-Reply-To: On Thu, May 21, 2020 at 10:36 AM Matheus Tavares Bernardino wrote: > > On Thu, May 21, 2020 at 4:26 AM Elijah Newren wrote: > > > > On Tue, May 12, 2020 at 5:17 PM Junio C Hamano wrote: > > > > > > Matheus Tavares Bernardino writes: > > > > > > > The idea behind not skipping gitlinks here was to be compliant with > > > > what we have in the working tree. In 4fd683b ("sparse-checkout: > > > > document interactions with submodules"), we decided that, if the > > > > sparse-checkout patterns exclude a submodule, the submodule would > > > > still appear in the working tree. The purpose was to keep these > > > > features (submodules and sparse-checkout) independent. Along the same > > > > lines, I think we should always recurse into initialized submodules in > > > > Sorry if I missed it in the code, but do you check whether the > > submodule is initialized before descending into it, or do you descend > > into it based on it just being a submodule? > > We only descend if the submodule is initialized. The new code in this > patch doesn't do this check, but it is already implemented in > grep_submodule() (which is called by grep_tree() and grep_cache() when > a submodule is found). Good to know. To up the ante a bit: What if another branch has directory that doesn't exist in HEAD or the current checkout, and within that directory is a submodule. Would it be recursed into? What if it matched the sparsity paths? (Is it even possible to recurse into it?)