From: Junio C Hamano <hidden> Date: 2016-06-15 22:45:45
Daniel Barkalow [off-list ref] writes:
quoted
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.
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.
If you understand that, it is clear what "git grep -e frotz HEAD^" should
do. No checkout area is involved.
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:45:45
On Thu, 11 Dec 2008, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
quoted
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*
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).
--
Duy
From: Johannes Sixt <hidden> Date: 2016-06-15 22:45:46
Nguyen Thai Ngoc Duy schrieb:
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).
But what if the same persion notices a #define in a kdeutils header file
and want's to know whether it is unused in order to remove it:
$ git grep FOO
kdeutils/foo.h:#define FOO bar
Conclusion from this output: "It's only defined, but not used anywhere."
But this conclusion is not necessarily correct because FOO could be used
outside kdeutils.
So, no, "git grep" should disregard the checkout area.
-- Hannes
>> 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).
But what if the same persion notices a #define in a kdeutils header file
and want's to know whether it is unused in order to remove it:
$ git grep FOO
kdeutils/foo.h:#define FOO bar
"git grep --cached FOO" ?
Conclusion from this output: "It's only defined, but not used anywhere."
But this conclusion is not necessarily correct because FOO could be used
outside kdeutils.
So, no, "git grep" should disregard the checkout area.
-- Hannes
From: Junio C Hamano <hidden> Date: 2016-06-15 22:45:46
"Nguyen Thai Ngoc Duy" [off-list ref] writes:
On 12/12/08, Johannes Sixt [off-list ref] wrote:
...
quoted
But what if the same persion notices a #define in a kdeutils header file
and want's to know whether it is unused in order to remove it:
$ git grep FOO
kdeutils/foo.h:#define FOO bar
"git grep --cached FOO" ?
That should behave identically when the work tree does not have change
since the index, and by definition paths outside the checkout area in the
"sparse" mode cannot have changes, so "git grep FOO" should behave the
same and should find it.
From: Junio C Hamano <hidden> Date: 2016-06-15 22:45:46
"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.