git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Thomas Haller <thom311@gmail.com>, Git List <git@vger.kernel.org>
Subject: Re: segfault for git log --graph --no-walk --grep a
Date: Mon, 11 Feb 2013 12:36:52 -0800	[thread overview]
Message-ID: <7vvc9ylh97.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7v621ymxfv.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Mon, 11 Feb 2013 12:01:56 -0800")

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

> Jeff King <peff@peff.net> 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.

Thanks.

commit 6a76814cd08cac15c1faff5bd97c9e94ac8b6a01
Author: Jeff King <peff@peff.net>
Date:   Mon Feb 11 14:16:07 2013 -0500

    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.

  reply	other threads:[~2013-02-11 20:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-08 23:52 segfault for git log --graph --no-walk --grep a Thomas Haller
2013-02-09  0:05 ` Junio C Hamano
2013-02-09  0:22   ` Junio C Hamano
2013-02-09  0:27     ` Jeff King
2013-02-09  0:39       ` Junio C Hamano
2013-02-09  0:47         ` Junio C Hamano
2013-02-09  1:05           ` Jeff King
2013-02-09  1:08             ` Jeff King
2013-02-11 19:16           ` Jeff King
2013-02-11 20:01             ` Junio C Hamano
2013-02-11 20:36               ` Junio C Hamano [this message]
2013-02-11 20:41                 ` Jeff King
2013-02-11 20:55                   ` Junio C Hamano
2013-02-11 20:59               ` [PATCH] log: re-encode commit messages before grepping Jeff King
2013-02-11 21:11                 ` Junio C Hamano
2013-02-11 21:14                   ` Jeff King
2013-02-25  8:37                 ` [PATCH ] t4210-log-i18n: spell encoding name "UTF-8" correctly Johannes Sixt
2013-02-25 15:19                   ` Jeff King
2013-02-25 19:06                     ` Junio C Hamano
2013-02-25 20:31                       ` Jeff King
2013-02-26  6:47                         ` Johannes Sixt
2013-02-25 21:00                     ` Torsten Bögershausen
2013-02-25 18:54                   ` Torsten Bögershausen
2013-02-25 20:36                     ` Jeff King
2013-02-09  0:29     ` segfault for git log --graph --no-walk --grep a Junio C Hamano
2013-02-09  0:39       ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vvc9ylh97.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=thom311@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).