Re: fatal: git grep: cannot generate relative filenames containing '..'

From: Hannu Koivisto <azure@iki.fi>
Date: Jan 17, 2009, 02:21 UTC
Message-ID: <83vdsefz9j.fsf@kalahari.s2.org>
In-Reply-To: <7vr634ow3r.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 6 quoted lines

> "George Spelvin" <linux@horizon.com> writes:
>
>> Could someone fix this some day?
>
> As far as I know you are the first to ask for this, so perhaps people never
> considered this was something to "fix"....

I for one have faced that problem and considered it something that would be nice to have fixed. Then again, I consider the default behaviour (when you pass no path) a bigger usability problem.

>> While you're at it, an option to search the entire git tree rather than
>> the current subdirectory would also be useful.  I was thinking about
>> a flag like -r (for "root"),...

It turns out that this "entire git tree" is practically my only use case when using normal (find and) grep and when I first tried git grep, I actually expected it to do just that with no path specified.

Why? Because of the way at least git diff and git log work. I thought that just like with them, "git grep foo" would search the entire git tree and I would have to say "git grep foo ." to limit to the current directory and its subdirectories. git-grep(1)'s "Look for specified patterns in the working tree files..." at least didn't seem to disagree with my expectation so I was a bit puzzled.

So I'd rather see git grep behave in a way consistent with git log and git diff (I realize that would change current behaviour instead of extending it).

-- 
Hannu