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

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

[Bert Wesarg]

Hi,

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. But this does not work ether:

    cd ~; git grep --no-index foo ~/.bashrc

They all fail with 'is outside repository'. Which is for itself vary
misleading, because I intentionally said --no-index.

Any input is appreciate.

Thanks.

Bert

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

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Fri, 2011-10-21 at 08:34 +0200, Bert Wesarg wrote:
> Hi,
> 
> 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. But this does not work ether:

The rest of the sentence reads ", not just those tracked by git" which
implies that the files tracked by git are also searched. This requires a
git repository.

> 
>     cd ~; git grep --no-index foo ~/.bashrc
> 
> They all fail with 'is outside repository'. Which is for itself vary
> misleading, because I intentionally said --no-index.

Git is a tool that works on git repositories. Some commands may work
outside of a repository, like ls-remote when given an URL or init (for
obvious reasons) but it's not something that should be expected,
especially for commands that read files from the working tree.

Why are you trying to use git's grep command outside a repository? Why
isn't 'grep -nr foo /usr/include/' good enough?

   cmn


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Lars Noschinski]

* Carlos Martín Nieto <cmn@elego.de> [11-10-21 09:09]:
> On Fri, 2011-10-21 at 08:34 +0200, Bert Wesarg wrote:
> > 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. But this does not work ether:
> 
> The rest of the sentence reads ", not just those tracked by git" which
> implies that the files tracked by git are also searched. This requires a
> git repository.

git grep --no-index works outside of git repositories (at least with
relative paths).

> >     cd ~; git grep --no-index foo ~/.bashrc
> > 
> > They all fail with 'is outside repository'. Which is for itself vary
> > misleading, because I intentionally said --no-index.
> 
> Git is a tool that works on git repositories. Some commands may work
> outside of a repository, like ls-remote when given an URL or init (for
> obvious reasons) but it's not something that should be expected,
> especially for commands that read files from the working tree.
> 
> Why are you trying to use git's grep command outside a repository? Why
> isn't 'grep -nr foo /usr/include/' good enough?

There are a few nice things about git's grep, which GNU grep does not
have:

  - automatic usage of pager
  - support for pathspecs (can be emulated with `find ...`)
  - support for boolean combinations of regular expressions

  -- Lars.

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

[Bert Wesarg]

On Fri, Oct 21, 2011 at 13:49, Lars Noschinski
<lars@public.noschinski.de> wrote:
>  - automatic usage of pager
>  - support for pathspecs (can be emulated with `find ...`)
>  - support for boolean combinations of regular expressions
- thread parallel

bert

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

[Junio C Hamano]

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

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.

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

[Bert Wesarg]

On Fri, Oct 21, 2011 at 19:00, Junio C Hamano <gitster@pobox.com> wrote:
> 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