Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)

>  >  - for "git grep", we ignore path with CE_NO_CHECKOUT (while using
>  > cache version for CE_VALID)
>
>
> Is this sufficient? I'd expect "git grep" to ignore paths that are outside
>  the checked-out region, even when searching an arbitrary tree, and even
>  when those files aren't in the index at all (i.e., the current commit
>  doesn't have them). That is, I'd expect core.defaultsparse or the
>  equivalent to limit the paths, normally giving this effect.

>  > >  The question, then, is what happens when the index and core.defaultsparse
>  > >  disagree, either because the porcelain supports causing it or because the
>  > >  user has simply editting the config file or used plumbing to modify the
>  > >  index. That is, (1) we have index entries that say that the worktree is
>  > >  ignored, and the rules don't say they're outside the sparse checkout; do
>  > >  we care whether we expect the worktree to be empty or match the index?
>  > >  And, (2) we have index entries that say we do care about them, but the
>  > >  rules say they're outside the sparse checkout; what happens with these?
>  >
>  > The rule is CE_NO_CHECKOUT is king. core.defaultsparse only helps
>  > setting CE_NO_CHECKOUT on new entries when they enter the index.
>
>
> This seems like a really bad idea to me. If you ask for a file that's
>  outside your default area to be checked out, and then you switch branches
>  and switch back, the file may or may not disappear (depending on whether
>  the branch you switched to temporarily had it or not). Likewise, if you
>  remove files, and then switch branches and back, the files may or may not
>  reappear.