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

[Elijah Newren <newren@gmail.com>]

On Wed, Jun 10, 2020 at 9:23 AM Matheus Tavares Bernardino
<matheus.bernardino@usp.br> wrote:
>
> 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