Hi, On Mon, 26 May 2008, Nguyen Thai Ngoc Duy wrote: > On Mon, May 26, 2008 at 6:00 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > On Mon, 26 May 2008, Nguyen Thai Ngoc Duy wrote: > > > >> On Mon, May 26, 2008 at 5:16 PM, Johannes Schindelin > >> <Johannes.Schindelin@xxxxxx> wrote: > >> > Besides, it would be a kludge at best to work _twice_ to find out > >> > the search terms, once in the external grep, and a second time in > >> > the coloring code. So I think it should not be done. > >> > >> I think if it's GNU grep, just passing it --color, it will grep and > >> colorize search terms in one turn. > > > > And what tells you that the called grep is GNU grep? > > A newly added macro like HAS_GNU_GREP? Granted it won't work all the > time. The user who set the macro should know what he is doing. This > approach is IMHO fine as long as we don't allow color customization. IMO this is just a kludge that is not even necessary, because the whole notion of relying on an external grep's colorization is crap. The OP has a patch that adds colorization to Git's internal grep code. The user specifies "--color" with grep? Fine, then it's no external grep. Full stop. Just like the original patch implements it. Nice, simple, and easy. What is so wrong with that? Ciao, Dscho -- 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
