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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 21, 2011, 17:00 UTC
Message-ID: <7vipni8el6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAKPyHN138OZRt_3PT5ChuTpSEuOdybnyAj8Baqr=3OD=y==jgw@mail.gmail.com>

Bert Wesarg <bert.wesarg@googlemail.com> writes:

Show 6 quoted lines

> 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

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.