From: Jonathan Nieder <jrnieder@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Andreas Krey <a.krey@gmx.de>
Subject: [PATCH] cherry-pick: do not dump core when iconv fails
Date: Sat, 8 May 2010 18:17:29 -0500 [thread overview]
Message-ID: <20100508231729.GA6718@progeny.tock> (raw)
In-Reply-To: <20100430133228.GA1620@progeny.tock>
When cherry-picking, usually the new and old commit encodings are both
UTF-8. Most old iconv implementations do not support this trivial
conversion, so on old platforms, out->message remains NULL, and later
attempts to read it segfault.
Fix this by noticing the input and output encodings match and skipping
the iconv step, like the other reencode_string() call sites already do.
Also stop segfaulting on other iconv failures: if iconv fails for some
other reason, the best we can do is to pass the old message through.
This fixes a regression introduced in v1.7.1-rc0~15^2~2 (revert:
clarify label on conflict hunks, 2010-03-20).
Reported-by: Andreas Krey <a.krey@gmx.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Andreas reported this cherry-pick regression about a week ago, and a
patch similar to this one seemed to fix it. The only question that
made me stall was what to do if iconv just doesn’t understand an
encoding:
- from a certain point of view it might make sense to pass through
the message and note the old encoding
- but on the other hand, that would not respect the user’s preference
as expressed in i18n.commitencoding, and it would deny the caller
the chance to fix the encoding problem in a text editor before
commiting.
That second point was driven home when I tried to implement this: it
required teaching ‘git commit’ to respect a new GIT_COMMIT_ENCODING
variable, but this was a pain (there is a sizeable amount of code
paying attention to i18n.commitencoding) and the result would have
been cherry-pick ignoring the $GIT_COMMIT_ENCODING preference,
creating encoding mismatches between ident and commit message to boot.
Everyone should be using utf8 anyway. :)
Anyway, this minimal fix should be safe (it just restores the old
behavior, except we do not use iconv for trivial conversions any
more). Patch is against v1.7.1-rc0~15^2~2.
Thanks to Andreas for the help.
builtin/revert.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 5a5b721..5adaf27 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -97,8 +97,13 @@ static int get_message(const char *raw_message, struct commit_message *out)
encoding = "UTF-8";
if (!git_commit_encoding)
git_commit_encoding = "UTF-8";
- if ((out->reencoded_message = reencode_string(raw_message,
- git_commit_encoding, encoding)))
+
+ out->reencoded_message = NULL;
+ out->message = raw_message;
+ if (strcmp(encoding, git_commit_encoding))
+ out->reencoded_message = reencode_string(raw_message,
+ git_commit_encoding, encoding);
+ if (out->reencoded_message)
out->message = out->reencoded_message;
abbrev = find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV);
--
1.7.1
next prev parent reply other threads:[~2010-05-08 23:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-28 19:38 Proper way to abort incorrect cherry-picking? Eugene Sajine
2010-04-28 19:49 ` David Borowitz
2010-04-28 19:59 ` Eugene Sajine
2010-04-28 22:39 ` Jon Seymour
2010-04-28 23:37 ` Jonathan Nieder
2010-04-29 0:07 ` Jon Seymour
2010-04-29 19:11 ` git cherry(pick) dumps core Andreas Krey
2010-04-29 19:49 ` Jonathan Nieder
2010-04-29 20:21 ` Andreas Krey
2010-04-30 13:32 ` Jonathan Nieder
2010-05-08 23:17 ` Jonathan Nieder [this message]
2010-05-08 23:55 ` [PATCH] cherry-pick: do not dump core when iconv fails Junio C Hamano
2010-04-28 19:50 ` Proper way to abort incorrect cherry-picking? Jonathan Nieder
2010-04-28 20:05 ` Eugene Sajine
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100508231729.GA6718@progeny.tock \
--to=jrnieder@gmail.com \
--cc=a.krey@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.