Re: git grep --no-index and absolute paths don't work?

From: Bert Wesarg <bert.wesarg@googlemail.com>
Date: Oct 21, 2011, 17:35 UTC
Message-ID: <CAKPyHN3oLC-F2pBZtBu4494V5UR6-yALzCsTkDmG7-a13YCnng@mail.gmail.com>
In-Reply-To: <7vipni8el6.fsf@alter.siamese.dyndns.org>

On Fri, Oct 21, 2011 at 19:00, Junio C Hamano <gitster@pobox.com> wrote:

Show 23 quoted lines

> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>> I'm currently  totally confused, that a
>>
>>     git grep --no-index foo /usr/include
>>
>> does not work. I know that the documentation says "in the current
>> directory" for the --no-index flag.
>
> I think "in the current directory" is just contrasting with "in the work
> tree, ..." at the beginning of the DESCRIPTION section. We could say "in
> the files" instead for clarity, and then add "when pathspec is not given,
> files in the current directory is searched" or something.
>
> The intent of "--no-index", originating from "git diff --no-index", is to
> allow git tools to be used in non-git context, i.e. to files on the
> filesystem.
>
> "git grep --no-index" which is a later invention in the 1.7.0 era didn't
> fully ignore "git"ness, and one such instance you fixed in this thread:
>
>    http://thread.gmane.org/gmane.comp.version-control.git/181484/focus=181485
>

Thats why I'm completely rattled after trying an absolute path with --no-index and it didn't worked.

> I think this path normalization is another instance of us knowing a bit too
> much of "git" even when we are told with "--no-index" that we are not
> operating on a working tree associated with git.
>

So we agree that this is a bug. Good. I will try to have a look into this.

Bert