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

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

On 12/9/08, Daniel Barkalow [off-list ref] wrote:

quoted

 >  - 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.

quoted

 > >  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*