Jeff King <peff@xxxxxxxx> writes: > On Mon, Feb 11, 2013 at 12:36:52PM -0800, Junio C Hamano wrote: > >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >> > Jeff King <peff@xxxxxxxx> writes: >> > >> >> On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote: >> >> >> >>> > Yeah, that actually is a good point. We should be using logmsg_reencode >> >>> > so that we look for strings in the user's encoding. >> >>> >> >>> Perhaps like this. Just like the previous one (which should be >> >>> discarded), this makes the function always use the temporary strbuf, >> >>> so doing this upfront actually loses more code than it adds ;-) >> >> >> >> I didn't see this in What's Cooking or pu. We should probably pick an >> >> approach and go with it. >> >> >> >> I think using logmsg_reencode makes sense. I'd be in favor of avoiding >> >> the extra copy in the common case, so something like the patch below. If >> >> you feel strongly about the code cleanup at the minor run-time expense, >> >> I won't argue too much, though. >> > >> > Sounds good to me. Care to do the log message while at it? >> >> Heh, how about this? I still need a sign-off from you. > > I'm working on the log message and tests right now. There's also a minor > code fixup needed to compile with -Wall. Thanks; I noticed the constness issue around the message variable as well. > >> log --grep: look for the given string in log output encoding >> >> We used to grep in the raw commit buffer contents, possibly pieces >> of notes encoded in log output encoding appended to it, which was >> insane. >> >> Convert the contents of the commit message also to log output >> encoding before looking for the string. This incidentally fixes a >> possible NULL dereference that can happen when commit->buffer has >> already been freed, which can happen with >> >> git commit -m 'text1' --allow-empty >> git commit -m 'text2' --allow-empty >> git log --graph --no-walk --grep 'text2' >> >> which arguably does not make any sense (--graph inherently wants a >> connected history, and by --no-walk the command line is telling us >> to show discrete points in history without connectivity), and we >> probably should forbid the combination, but that is a separate >> issue. > > I'll use bits of that. I had sort of punted on the "how to reproduce the > segfault" issue entirely because you had noted that it was not a sane > thing to do. Still, I think it makes sense to mention it with the caveat > you give here. > > -Peff -- 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