On Thu, 11 Dec 2008, Junio C Hamano wrote: > Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > > >> 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. > > Let's step back a bit. I think "git grep" that stays silent outside of > the checkout area when used to grep in the work tree or in the index is a > mistake. > > The problem "sparse checkout" attempts to address is not this: > > I ran "git init && git add ." in /usr/src by mistake. There is no > reason for coreutils that is in /usr/src/coreutils and gnucash that is > in /usr/src/gnucash to share the same development history nor their > should be any ordering between commits in these two independent > projects. I should have done N separate "init & add" independently at > one level deeper in the directory hierarchy, but I am too lazy to > filter branch the resulting mess now. > > At least, it should not be that, at least to me. > > "Sparse" is "I am not going to modify the files in these areas, and I know > they do not need to be present for my purposes (e.g. build), so I do not > need copies in the work tree." It still works on the whole tree structure > recorded in the commit, but gives you a way to work inside a sparsely > populated work tree, iow, without checking everything out. There's the meta question of: "Do people who have declared that they aren't going to modify or build with some files want their searches to tell them about those files?" Say I'm the "tr" guy, and I care about the build system, library code, and "tr.c", and I run "make tr"; my sparse checkout doesn't include "head.c", and I totally ignore all the other stuff that's in coreutils. Maybe I want "git grep" to exclude the other stuff. I don't really have a firm position on whether "git grep" should ignore "head.c" or not, but I think it should be consistent between "git grep" and "git grep origin/next", and I think that, if origin/next has a new "foot.c" that isn't in the current branch to by marked as NO_CHECKOUT, it should be skipped if "tail.c" (which is in my current branch) is skipped. > So "git grep -e frotz Documentation/", whether you only check out > Documentation or the whole tree, should grep only in Documentation area, > and "git grep -e frotz" should grep in the whole tree, even if you happen > to have a sparse checkout. By definition, a sparse checkout has no > modifications outside the checkout area, so whenever grep wants to look > for strings outside the checkout area it should pretend as if the same > content as what the index records is in the work tree. This is consistent > with the way how "git diff" in a sparsely checked out work tree should > behave. "git diff" is an ambiguous model for "git grep". It equally describes the behavior of "git diff" to say that it treats files outside the checkout area as matching the index or to say that it never lists files outside the checkout area. On the other hand, there is the question of whether "git diff branch1 branch2" shows differences that are outside the checkout area, and whether "git log" shows commits that only change things outside the checkout area, and "git grep" should match the behavior of these. -Daniel *This .sig left intentionally blank* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
