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

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Dec 11, 2008, 20:30 UTC
Message-ID: <alpine.LNX.1.00.0812111520490.19665@iabervon.org>
In-Reply-To: <fcaeb9bf0812110504u1acfb612he3edae1df3774045@mail.gmail.com>

On Thu, 11 Dec 2008, Nguyen Thai Ngoc Duy wrote:

Show 15 quoted lines

> On 12/9/08, Daniel Barkalow <barkalow@iabervon.org> wrote:
> >  >  - 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.
> 
> That's the point. CE_VALID does not define checkout area while
> CE_NO_CHECKOUT does.  If an entry is CE_VALID, it is still in checkout
> area. But if it is CE_NO_CHECKOUT, "git grep" should ignore that path.
> core.defaultsparse has nothing to do here.

My point is that the index cannot tell git grep whether it should search a path if the path isn't in the index. If I do a narrow checkout of only Documentation/, and I do "git grep foo", I won't see files that aren't in Documentation/; if I do "git grep foo origin/next", I think I shouldn't see files that aren't in Documentation/, and "new-program.c" isn't in my index at all, marked as CE_NO_CHECKOUT or otherwise, so git grep can't find out from the index whether that file is outside my area of interest. It needs to be able to determine that "only Documentation/ is in the checkout area" ignoring the details of the list of files in the working directory currently in or out of the area.

Show 25 quoted lines

> >  > >  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.
> 
> Well, if you set core.defaultsparse properly, those files should
> appear/disappear as you wish (and as of now if you define your
> checkout area with "git checkout --{include-,exclude-,}sparse" then
> core.defaultsparse should be updated accordingly). I don't say
> core.defaultsparse is perfect.

Right, so in order to get reasonable behavior, the user must use --{include,exclude}-sparse. I think that this should be the *default* behavior, and probably the *only porcelain-supported* behavior, because otherwise it's confusing.

	-Daniel
*This .sig left intentionally blank*