On Mon, May 2, 2011 at 21:08, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> writes: > >>> Â- Are there existing non-git "grep" implementations that do this? >> >> I didn't know of any, until Jakub mentioned the ack tool. And I didn't >> look for one. I will answer you 'yes'-questions only in context of my >> proposal. > > Thanks, but these questions are simple sanity checks done by contrasting > your design with _existing practices_, if any. ÂIt is not useful to answer > what you did here, only to contrast your design with itself. I should probably have written 'I *can only* answer...', but I appreciate your questions anyhow, even if I can't answer them all. > > Also we can read them from your implementation ;-). > >>> Â - perhaps people use something like "sed -n -e 25,30p file" and be >>> Â Â happy? >> >> How would you combine this with git grep HEAD or with multiple files? > > Now how did you get the compiler error messages from your example from the > files in HEAD commit without checking them out? Haven't you heard of the git-gcc extension yet. Just kidding and point taken. But I think/hope there are some more use cases than my own for this feature, else I wouldn't have send the patches out. Bert > > Besides, that question is still part of figuring out prior art done in the > git-unaware grep, so it is irrelevant that sed or other people's grep > cannot peek into HEAD. > -- 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