On Sun, Feb 14, 2010 at 8:45 PM, Junio C Hamano <gitster@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html