On Fri, 20 Apr 2007, Jakub Narebski wrote:
Andy Parkins wrote:
* We do not do the borrowing from working tree when doing
grep_sha1(), but when we grep inside a file from working tree
with grep_file(), we do not currently make it go through
convert_to_git() to fix line endings. Maybe we should, if
only for consistency.
I'd actually argue not - git-grep searches the working tree. The expanded
keywords are in the working tree. Take the CRLF case - I'm a clueless user,
who only understands the system I'm working on. I want to search for all the
line endings, so I do git-grep "\r\n" - that should work, because I'm
searching my working tree.
Actually, "git grep" can search both the working tree (default), but also
an index (--cached), or specified tree (or tree-ish). The same with
"git diff": it can work on tree (repository), index, working tree version,
now I think in [almost] any combination.
Think what keyword expansion means to all this... Well, you can have -kk
to expand/not expand keywords, but this is avoiding issue, not solving it
how is git-grep on the working tree any different than just useing grep? the
value in the git-* versions of system commands are that they work on the
history, index, etc wher ethe normal system tools don't.
in this particular case, since the git user can do a git-grep of the working
tree, or a git-grep of HEAD (or of the index), I don't think that it hurts much
either way.
if git-grep of the working tree converts things to the checked-in version before
the pattern match, the user can still use grep to go through the checked-out
version
if git-grep of the working tree doesn't convert things to the checked-in version
before the pattern match, the user can stil use git-grep HEAD or --cached to go
through the checked-in version.
David Lang