From: Elijah Newren <newren@gmail.com> To: Matheus Tavares Bernardino <matheus.bernardino@usp.br> Cc: Git Mailing List <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>, Derrick Stolee <stolee@gmail.com>, Jonathan Tan <jonathantanmy@google.com> Subject: Re: [RFC PATCH v2 3/4] grep: honor sparse checkout patterns Date: Fri, 22 May 2020 14:06:35 -0700 Message-ID: <CABPp-BGEPU49yRN2FRtwhYn6Uh+scGKEFYP4G2GH6=uBTN1SCw@mail.gmail.com> (raw) In-Reply-To: <CAHd-oW6BoHkMSAQVquHR+H7=g84VE-qmXGYcDmWwFxuLyqZSzg@mail.gmail.com> On Fri, May 22, 2020 at 1:54 PM Matheus Tavares Bernardino <matheus.bernardino@usp.br> wrote: > > Hi, Elijah > > On Fri, May 22, 2020 at 12:36 PM Elijah Newren <newren@gmail.com> wrote: > > > > On Fri, May 22, 2020 at 7:26 AM Elijah Newren <newren@gmail.com> wrote: > > > > > > Hi Matheus, > > > > > > On Thu, May 21, 2020 at 10:49 PM Matheus Tavares Bernardino <matheus.bernardino@usp.br> wrote: > > > > > > > > On Thu, May 21, 2020 at 2:52 PM Elijah Newren <newren@gmail.com> wrote: > > > > > > > <snip> > > > > Does this seem like a good approach? Or is there another solution that > > > > I have not considered? Or even further, should we choose to skip the > > > > submodules in excluded paths? My only concern in this case is that it > > > > would be contrary to the design in git-sparse-checkout.txt. And the > > > > working tree grep and cached grep would differ even on a clean working > > > > tree. > > > > > <snip> > > > Anyway, the wording in that file seems to be really important, so > > > let's fix it. > > > > > > > Let me also try to give a concrete proposal for grep behavior for the > > edge cases we've discussed: > > Thank you for this proposal and for the previous comments as well. > > > git -c sparse.restrictCmds=true grep --recurse-submodules $PATTERN > > > > This goes through all the files in the index (i.e. all tracked files) > > which do not have the SKIP_WORKTREE bit set. For each of these: If > > the file is a symlink, ignore it (like grep currently does). If the > > file is a regular file and is present in the working copy, search it. > > If the file is a submodule and it is initialized, recurse into it. > > Sounds good. And when sparse.restrictCmds=false, we also search the > present files and present initialized submodules that have the > SKIP_WORKTREE set, right? You're really pushing those corner cases, I love it. :-) SKIP_WORKTREE is supposed to mean we have removed it from the working tree, i.e. it shouldn't be present (if we decide we're not going to remove it from the working tree, e.g. because the file is unmerged or something, then we don't mark it as SKIP_WORKTREE even if it doesn't match sparsity patterns). Therefore, the set of files that satisfy this condition you have given should generally be empty. But presuming we hit this corner case, I'd say you are right. sparse.restrictCmds=false means we ignore the SKIP_WORKTREE bit entirely (and in the case of grepping a $REVISION, we ignore the sparsity patterns entirely). > > git -c sparse.restrictCmds=true grep --recurse-submodules --cached $PATTERN > > > > This goes through all the files in the index (i.e. all tracked files) > > which do not have the SKIP_WORKTREE bit set. For each of these: Skip > > symlinks. Search regular files. Recurse into submodules if they are > > initialized. > > OK. > > > git -c sparse.restrictCmds=true grep --recurse-submodules $REVISION $PATTERN > > > > This goes through all the files in the given revision (i.e. all > > tracked files) which match the sparsity patterns (i.e. that would not > > have the SKIP_WORKTREE bit set if were we to checkout that commit). > > For each of these: Skip symlinks. Search regular files. Recurse into > > submodules if they are initialized. > > OK. > > > Further, for any of these, when recursing into submodules, make sure > > to load that submodules' core.sparseCheckout setting (and related > > settings) and the submodules' sparsity patterns, if any. > > > > Sound good? > > > > I think this addresses the edge cases we've discussed so far: > > interaction between submodules and sparsity patterns, and handling of > > files that are still present despite not matching the sparsity > > patterns. (Also note that files which are present-despite-the-rules > > are prone to be removed by the next `git sparse-checkout reapply` or > > anything that triggers a call to unpack_trees(); there's already > > multiple things that do and Stolee's proposed patches would add more). > > If I've missed edge cases, let me know. > > Sounds great. This addresses all the edge cases we've mentioned > before. Thanks again for the detailed proposal, and for considering > case by case. And thank you for working on this. :-)
next prev parent reply index Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-24 6:04 [RFC PATCH 0/3] grep: honor sparse checkout and add option to ignore it Matheus Tavares 2020-03-24 6:11 ` [RFC PATCH 1/3] doc: grep: unify info on configuration variables Matheus Tavares 2020-03-24 7:57 ` Elijah Newren 2020-03-24 21:26 ` Junio C Hamano 2020-03-24 23:38 ` Matheus Tavares 2020-03-24 6:12 ` [RFC PATCH 2/3] grep: honor sparse checkout patterns Matheus Tavares 2020-03-24 7:15 ` Elijah Newren 2020-03-24 15:12 ` Derrick Stolee 2020-03-24 16:16 ` Elijah Newren 2020-03-24 17:02 ` Derrick Stolee 2020-03-24 23:01 ` Matheus Tavares Bernardino 2020-03-24 22:55 ` Matheus Tavares Bernardino 2020-04-21 2:10 ` Matheus Tavares Bernardino 2020-04-21 3:08 ` Elijah Newren 2020-04-22 12:08 ` Derrick Stolee 2020-04-23 6:09 ` Matheus Tavares Bernardino 2020-03-24 6:13 ` [RFC PATCH 3/3] grep: add option to ignore sparsity patterns Matheus Tavares 2020-03-24 7:54 ` Elijah Newren 2020-03-24 18:30 ` Junio C Hamano 2020-03-24 19:07 ` Elijah Newren 2020-03-25 20:18 ` Junio C Hamano 2020-03-30 3:23 ` Matheus Tavares Bernardino 2020-03-31 19:12 ` Elijah Newren 2020-03-31 20:02 ` Derrick Stolee 2020-04-27 17:15 ` Matheus Tavares Bernardino 2020-04-29 16:46 ` Elijah Newren 2020-04-29 17:21 ` Elijah Newren 2020-03-25 23:15 ` Matheus Tavares Bernardino 2020-03-26 6:02 ` Elijah Newren 2020-03-27 15:51 ` Junio C Hamano 2020-03-27 19:01 ` Elijah Newren 2020-03-30 1:12 ` Matheus Tavares Bernardino 2020-03-31 16:48 ` Elijah Newren 2020-05-10 0:41 ` [RFC PATCH v2 0/4] grep: honor sparse checkout and add option to ignore it Matheus Tavares 2020-05-10 0:41 ` [RFC PATCH v2 1/4] doc: grep: unify info on configuration variables Matheus Tavares 2020-05-10 0:41 ` [RFC PATCH v2 2/4] config: load the correct config.worktree file Matheus Tavares 2020-05-11 19:10 ` Junio C Hamano 2020-05-12 22:55 ` Matheus Tavares Bernardino 2020-05-12 23:22 ` Junio C Hamano 2020-05-10 0:41 ` [RFC PATCH v2 3/4] grep: honor sparse checkout patterns Matheus Tavares 2020-05-11 19:35 ` Junio C Hamano 2020-05-13 0:05 ` Matheus Tavares Bernardino 2020-05-13 0:17 ` Junio C Hamano 2020-05-21 7:26 ` Elijah Newren 2020-05-21 17:35 ` Matheus Tavares Bernardino 2020-05-21 17:52 ` Elijah Newren 2020-05-22 5:49 ` Matheus Tavares Bernardino 2020-05-22 14:26 ` Elijah Newren 2020-05-22 15:36 ` Elijah Newren 2020-05-22 20:54 ` Matheus Tavares Bernardino 2020-05-22 21:06 ` Elijah Newren [this message] 2020-06-10 11:40 ` Derrick Stolee 2020-06-10 16:22 ` Matheus Tavares Bernardino 2020-06-10 17:42 ` Derrick Stolee 2020-06-10 18:14 ` Matheus Tavares Bernardino 2020-06-10 20:12 ` Elijah Newren 2020-06-10 19:58 ` Elijah Newren 2020-05-21 7:36 ` Elijah Newren 2020-05-10 0:41 ` [RFC PATCH v2 4/4] config: add setting to ignore sparsity patterns in some cmds Matheus Tavares 2020-05-10 4:23 ` Matheus Tavares Bernardino 2020-05-21 17:18 ` Elijah Newren 2020-05-21 7:09 ` Elijah Newren 2020-05-28 1:12 [PATCH v3 0/5] grep: honor sparse checkout and add option to ignore it Matheus Tavares 2020-05-28 1:12 ` [PATCH v3 1/5] doc: grep: unify info on configuration variables Matheus Tavares
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CABPp-BGEPU49yRN2FRtwhYn6Uh+scGKEFYP4G2GH6=uBTN1SCw@mail.gmail.com' \ --to=newren@gmail.com \ --cc=git@vger.kernel.org \ --cc=gitster@pobox.com \ --cc=jonathantanmy@google.com \ --cc=matheus.bernardino@usp.br \ --cc=stolee@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Mailing List Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/git/0 git/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 git git/ https://lore.kernel.org/git \ git@vger.kernel.org public-inbox-index git Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git