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. > 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