From: Mark Lodato Date: Tue, 16 Feb 2010 00:20:30 GMT Subject: Re: git-grep ignores untracked files Message-ID: In-Reply-To: <7vvddz5l1z.fsf@alter.siamese.dyndns.org> On Sun, Feb 14, 2010 at 8:45 PM, Junio C Hamano 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 " 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 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. >> +...:: >> +     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.