Re: git-grep ignores untracked files

[Mark Lodato <lodatom@gmail.com>]

On Sun, Feb 14, 2010 at 8:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

>> +<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.