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

From: Elijah Newren <newren@gmail.com>
Date: Jun 10, 2020, 20:12 UTC
Message-ID: <CABPp-BFW7iXwG20h15=DJJCsaRCPbB3fmXicvxGie1aTtHW4Gw@mail.gmail.com>
In-Reply-To: <CAHd-oW7BXWzaWsvsh0dQt7NgeBcz0HSbcwKVYA7sPjUinarsng@mail.gmail.com>

On Wed, Jun 10, 2020 at 9:23 AM Matheus Tavares Bernardino <matheus.bernardino@usp.br> wrote:

Show 24 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/

I flagged some issues with that sentence...and an additional issue in my original sentence besides the one Stolee flagged. It seems to be easy to mess up a simple summary here. :-)

But I do want a simple summary of some sort; I want Documentation/git-sparse-checkout.txt to be an end-user guide and not an implementation spec. Perhaps I can bring up a simpler example that will make it easier to see my distinction between the two -- let's consider the case of unmerged files. I think all of the following statements are true, but some are meant strictly as implementation details of relevant subcommands, while others are deduced overall behavior observed by end-users:

* If you just ran merge or rebase and have some files with conflicts,
'git grep searchstring' will search the conflicted files for the
searchstring
* When searching the working tree, git grep should not do any special
checking for whether files are in a conflicted state
* sparse-checkout will never set the SKIP_WORKTREE bit on an unmerged
file (despite sparsity patterns)
* sparse-checkout will delete all (regular and symlink) files from the
working tree when it sets the SKIP_WORKTREE bit for them
* sparse-checkout will not delete files from the working copy if it
doesn't set the SKIP_WORKTREE bit on it
* When merging, if the merge machinery notices a conflict, it must
clear the SKIP_WORKTREE bit and write the (conflicted version of the)
file out to the working tree.  (It is also allowed to clear the
SKIP_WORKTREE bit for files that are not conflicted, though we'd
rather it didn't do that so much.)

These statements above are not incompatible, because some deal with the implementation of git grep (the second item), others deal with implementation details of other commands or machinery (all items after the second), and the first item deals with the combination of behaviors between sparse-checkout + merge machinery + grep.

So, even though the first bullet point says "git grep...will search the conflicted files" that does NOT mean git grep should check for whether files are conflicted. My proposed update in v2 that I'll send out (once I come up with one) might use similar broad brushes.

Hope that helps, Elijah