Re: git-grep ignores untracked files

From: Mark Lodato <lodatom@gmail.com>
Date: Feb 16, 2010, 00:20 UTC
Message-ID: <ca433831002151620q2b875c51md883f4b424231f15@mail.gmail.com>
In-Reply-To: <7vvddz5l1z.fsf@alter.siamese.dyndns.org>

On Sun, Feb 14, 2010 at 8:45 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 5 quoted lines

> I doubt we want to have "Only tracked files blah blah".  Like all the
> normal git commands, "grep" is about tracked contents, and I don't think
> it would help to repeat the obvious like pathspec filter will act as a
> filter.  "add <pathspec>" is an exception in that it _is_ about untracked
> paths and that is why you get warnings for unmatched ones.

I think adding this information to the description of <path> would be sufficient. I'll send a new patch in a minute.

>    Side note: there will be --no-index option to let you run "git grep"
>    over files in a random directory.

Ah, didn't see this. So, it looks like most of my requests were already done. However, it may still be a good idea to DWIM when none of --cached, --no-index, or trees are given but a pathspec is given that matches an untracked file in the working directory. For example:

$ git grep $pattern -- untracked_file

It is obvious that the user meant to specify --no-index. However, I'm not sure where to draw the line. What if they give tracked and untracked files, or if they given a glob pattern that matches both?

Still, the simple, "one path is given, it's not a pattern, and it matches exactly to an untracked file" case should probably run with --no-index.

Show 9 quoted lines

>> +<path>...::
>> +     Only search files matching these wildcard patterns; see glob(7) for
>> +     the format.  If not given, all tracked files in the tree are searched.
>
> Please do *not* "see glob(7) for the format".  Pathspec used for "grep"
> (and "ls-files") are "leading path match or glob(7)".  E.g. "git grep
> frotz t/" looks for frotz in all files under "t/" recursively, and that
> does not have much to do with glob(7).  If we do not have a description
> already, we may want to add these basics to git(1) or the user manual.

Ah. This is a major inconsistency in the documentation. I have a lot to say about this, so I'll make this a separate thread. For the patch, I'll just reference git-add(1), which is the does have a description, and then we can fix this properly in a future patch.