From: David Lang Date: Sat, 21 Apr 2007 00:47:10 GMT Subject: Re: [PATCH 2/2] Add keyword unexpansion support to convert.c Message-ID: In-Reply-To: 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