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

"Nguyen Thai Ngoc Duy" [off-list ref] writes:

On 12/12/08, Junio C Hamano [off-list ref] wrote:

quoted

 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.

Assume someone is using sparse checkout with KDE git repository. They
sparse-checkout kdeutils module and do "git grep -e foo". I would
expect that the command only searches in kdeutils only (and is the
current behavior).

Yes it is the "current in next" behaviour, and no that is not what you
should expect, and that is why I earlier said it is a mistake.  The
ability to choose which part to leave out of the working tree should not
change the fact that git is about managing the history of the whole tree,
not an individual file nor a subset of files.

I do not think it is unreasonable to have a mechanism to let the user
limit the area of the whole tree often used Porcelain commands look at.
We already have pathspec "git grep -e foo kdeutils/" mechanism that lets
you do such limiting.  It is conceivable that some workflows _might_ find
having the default pathspec convenient in end-user initiated operations,
but then it would be convenient whether the end-user uses the sparse
checkout to limit the area to kdeutils/ or has the whole checkout.
Although I think it would be Okay to default the default pathspec match
the checkout area when the sparse checkout feature is in use, I think the
"checkout area" and "area of interest" should be two independent concepts.

I said "_might_" in the above because I do not think it is such a good
idea to have _the_ default pathspec to begin with, though.  It would
probably be more useful to allow people to use shorthands to pathspecs,
and at that point you can use usual shell variables to do that already,
e.g. instead of having to say "git grep -e foo arch/x86 include/asm-i386",
you would say "git grep -e foo $i386", after "i386=arch/x86 include/asm-i386",
or something like that.