{"thread":{"id":"23632","subject":"Proper way to abort incorrect cherry-picking?","startedAt":"2010-04-28T19:38:15Z","lastAt":"2010-05-08T23:55:56Z","messageCount":14,"participants":["Eugene Sajine","Jonathan Nieder","David Borowitz","Jon Seymour","Andreas Krey","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140602","messageId":"s2m76c5b8581004281238jf7179fffna7d757fee6ab4f10@mail.gmail.com","threadId":"23632","inReplyTo":null,"subject":"Proper way to abort incorrect cherry-picking?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-28T19:38:15Z","receivedAt":"2010-04-28T19:38:15Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"hi,\n\nwe have tried to cherry-pick 2 commits from one branch to another\nbranch, but unfortunately the incorrect commit was chosen to be\napplied first.\n\nThus, the automatic cherry-pick failed and caused conflicts, so in\norder to to cancel the whole operation i had to do the following:\n\n1. mark the conflicting files as resolved (without even resolving\nthem) by doing git add.\n2. unstage all files staged for commit as a result of incomplete cherry picking\n3. manually checkout touched files to their correct state (git checkout file)\n\nand then i was able to repeat cherry-picking with correct commits.\n\nIs there a better way? Shouldn't there be a \"git cherry-pick --abort\"\nfor such cases as it exists for rebase?\n\nThanks,\nEugene\n"},{"id":"140604","messageId":"r2s302ed1461004281249xd1b65e41l43fa7b639db7c97d@mail.gmail.com","threadId":"23632","inReplyTo":"s2m76c5b8581004281238jf7179fffna7d757fee6ab4f10@mail.gmail.com","subject":"Re: Proper way to abort incorrect cherry-picking?","fromName":"David Borowitz","fromEmail":"dborowitz@google.com","sentAt":"2010-04-28T19:49:55Z","receivedAt":"2010-04-28T19:49:55Z","isPatch":false,"sender":{"key":"dborowitz@google.com","avatar":"https://avatars.githubusercontent.com/u/194927?v=4"},"body":"On Wed, Apr 28, 2010 at 12:38, Eugene Sajine wrote:\n>\n> hi,\n>\n> we have tried to cherry-pick 2 commits from one branch to another\n> branch, but unfortunately the incorrect commit was chosen to be\n> applied first.\n>\n> Thus, the automatic cherry-pick failed and caused conflicts, so in\n> order to to cancel the whole operation i had to do the following:\n>\n> 1. mark the conflicting files as resolved (without even resolving\n> them) by doing git add.\n> 2. unstage all files staged for commit as a result of incomplete cherry picking\n> 3. manually checkout touched files to their correct state (git checkout file)\n>\n> and then i was able to repeat cherry-picking with correct commits.\n>\n> Is there a better way?\n\ngit reset --hard HEAD@{1}?\n\n> Shouldn't there be a \"git cherry-pick --abort\"\n> for such cases as it exists for rebase?\n\nISTM the --abort flag to rebase is useful because HEAD may have\nchanged an arbitrary number of times between the start of the rebase\nand now, so you wouldn't know which reflog entry to choose. (The same\nholds for \"git bisect reset\".) But with a cherry-pick it's always\n@{1}.\n\n> Thanks,\n> Eugene\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"140603","messageId":"20100428195001.GA2242@progeny.tock","threadId":"23632","inReplyTo":"s2m76c5b8581004281238jf7179fffna7d757fee6ab4f10@mail.gmail.com","subject":"Re: Proper way to abort incorrect cherry-picking?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-28T19:50:01Z","receivedAt":"2010-04-28T19:50:01Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eugene Sajine wrote:\n\n> the automatic cherry-pick failed and caused conflicts, so in\n> order to to cancel the whole operation i had to do the following:\n> \n> 1. mark the conflicting files as resolved (without even resolving\n> them) by doing git add.\n> 2. unstage all files staged for commit as a result of incomplete cherry picking\n> 3. manually checkout touched files to their correct state (git checkout file)\n> \n> and then i was able to repeat cherry-picking with correct commits.\n> \n> Is there a better way?\n\ngit reset --merge\n\nIdeas for where this should be put in the git-cherry-pick.txt manual?\n\nThanks,\nJonathan\n"},{"id":"140605","messageId":"h2v76c5b8581004281259yfaca7abfz5a455ff8fd6cdc6b@mail.gmail.com","threadId":"23632","inReplyTo":"r2s302ed1461004281249xd1b65e41l43fa7b639db7c97d@mail.gmail.com","subject":"Re: Proper way to abort incorrect cherry-picking?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-28T19:59:50Z","receivedAt":"2010-04-28T19:59:50Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Wed, Apr 28, 2010 at 3:49 PM, David Borowitz wrote:\n> On Wed, Apr 28, 2010 at 12:38, Eugene Sajine wrote:\n>>\n>> hi,\n>>\n>> we have tried to cherry-pick 2 commits from one branch to another\n>> branch, but unfortunately the incorrect commit was chosen to be\n>> applied first.\n>>\n>> Thus, the automatic cherry-pick failed and caused conflicts, so in\n>> order to to cancel the whole operation i had to do the following:\n>>\n>> 1. mark the conflicting files as resolved (without even resolving\n>> them) by doing git add.\n>> 2. unstage all files staged for commit as a result of incomplete cherry picking\n>> 3. manually checkout touched files to their correct state (git checkout file)\n>>\n>> and then i was able to repeat cherry-picking with correct commits.\n>>\n>> Is there a better way?\n>\n> git reset --hard HEAD@{1}?\n\nnot always working. In our particular case there were some local\nmodifications to other files, which would be blown away with this for\nno reason. That's why I went the long way of resetting specific files.\n\nThanks,\nEugene\n"},{"id":"140607","messageId":"s2l76c5b8581004281305i839693d6l400d4d7e1ca86e98@mail.gmail.com","threadId":"23632","inReplyTo":"20100428195001.GA2242@progeny.tock","subject":"Re: Proper way to abort incorrect cherry-picking?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-28T20:05:43Z","receivedAt":"2010-04-28T20:05:43Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Wed, Apr 28, 2010 at 3:50 PM, Jonathan Nieder wrote:\n> Eugene Sajine wrote:\n>\n>> the automatic cherry-pick failed and caused conflicts, so in\n>> order to to cancel the whole operation i had to do the following:\n>>\n>> 1. mark the conflicting files as resolved (without even resolving\n>> them) by doing git add.\n>> 2. unstage all files staged for commit as a result of incomplete cherry picking\n>> 3. manually checkout touched files to their correct state (git checkout file)\n>>\n>> and then i was able to repeat cherry-picking with correct commits.\n>>\n>> Is there a better way?\n>\n> git reset --merge\n>\n> Ideas for where this should be put in the git-cherry-pick.txt manual?\n>\n\nThat's interesting - thanks a lot!\n\nYes, it wold be nice to have it mentioned somewhere in help for cherry-picking.\n\nThanks,\nEugene\n"},{"id":"140612","messageId":"o2j2cfc40321004281539j28fe44e0r5d029061e3e08b90@mail.gmail.com","threadId":"23632","inReplyTo":"h2v76c5b8581004281259yfaca7abfz5a455ff8fd6cdc6b@mail.gmail.com","subject":"Re: Proper way to abort incorrect cherry-picking?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-04-28T22:39:40Z","receivedAt":"2010-04-28T22:39:40Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 29, 2010 at 5:59 AM, Eugene Sajine wrote:\n> On Wed, Apr 28, 2010 at 3:49 PM, David Borowitz wrote:\n>> On Wed, Apr 28, 2010 at 12:38, Eugene Sajine wrote:\n>>>\n>>> hi,\n>>>\n>>> we have tried to cherry-pick 2 commits from one branch to another\n>>> branch, but unfortunately the incorrect commit was chosen to be\n>>> applied first.\n>>>\n>>> Thus, the automatic cherry-pick failed and caused conflicts, so in\n>>> order to to cancel the whole operation i had to do the following:\n>>>\n>>> 1. mark the conflicting files as resolved (without even resolving\n>>> them) by doing git add.\n>>> 2. unstage all files staged for commit as a result of incomplete cherry picking\n>>> 3. manually checkout touched files to their correct state (git checkout file)\n>>>\n>>> and then i was able to repeat cherry-picking with correct commits.\n>>>\n>>> Is there a better way?\n>>\n>> git reset --hard HEAD@{1}?\n>\n> not always working. In our particular case there were some local\n> modifications to other files, which would be blown away with this for\n> no reason. That's why I went the long way of resetting specific files.\n>\n\nIf you use git reset --mixed HEAD@{1} you can reset the index to\nHEAD@{1} to reflect the pre-merge state. The unstaged changes will\nthen be a combination of the failed merge and the local modifications\nto the files. You can then revert the changes from the merge.\n\nThen you can use git stash to move the local modifications out of the\nway, then repeat the cherry pick in the correct order, then use git\nstash pop to reapply the local modifications to the working tree and\nindex.\n\nThis is more complicated than it needs to be - if you had stashed (or\ncommitted) before cherry picking, things would be simpler.\n\njon.\n\n> Thanks,\n> Eugene\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"140616","messageId":"20100428233758.GA1654@progeny.tock","threadId":"23632","inReplyTo":"o2j2cfc40321004281539j28fe44e0r5d029061e3e08b90@mail.gmail.com","subject":"Re: Proper way to abort incorrect cherry-picking?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-28T23:37:58Z","receivedAt":"2010-04-28T23:37:58Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Jon,\n\nJon Seymour wrote:\n\n> If you use git reset --mixed HEAD@{1} you can reset the index to\n> HEAD@{1} to reflect the pre-merge state.\n\nThe HEAD doesn’t advance in a failed merge, right?\n\n[...]\n> This is more complicated than it needs to be - if you had stashed (or\n> committed) before cherry picking, things would be simpler.\n\nIf this were really necessary, I would consider it a bug.\n\nI do think recovery is more complicated than it needs to be, since one\nhas to check whether the merge/cherry-pick failed before cancelling\nit. There are three cases.\n\n - If an early check prevented the operation (message with “fatal:”,\n status = 128), then the index and work tree were not touched.\n\n No recovery required.\n\n - If there were conflicts (message with “Conflicts:”, status = 1),\n the index will record the competing versions of conflicted files,\n and the work tree will represent the situation with conflict\n markers.\n\n Use ‘git reset --merge’ to recover.\n\n - If the merge proceeded cleanly (status = 0), but it was a bad\n idea after all, the index and work tree record the new version now.\n\n Use ‘git reset --keep HEAD@{1}’ to undo the operation.\n\nHave fun,\nJonathan\n"},{"id":"140617","messageId":"s2x2cfc40321004281707x50e59113t9f2ca9aea355ac5@mail.gmail.com","threadId":"23632","inReplyTo":"20100428233758.GA1654@progeny.tock","subject":"Re: Proper way to abort incorrect cherry-picking?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-04-29T00:07:27Z","receivedAt":"2010-04-29T00:07:27Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 29, 2010 at 9:37 AM, Jonathan Nieder wrote:\n> Hi Jon,\n>\n> Jon Seymour wrote:\n>\n>> If you use git reset --mixed HEAD@{1} you can reset the index to\n>> HEAD@{1} to reflect the pre-merge state.\n>\n> The HEAD doesn’t advance in a failed merge, right?\n\nTrue, but I understood this issue to be that there were two cherry\npicks, one of which worked, one of which failed because it was out of\norder. Hence git reset HEAD@{1} would reset prior to the first\nsuccessful (but out of order) cherry-pick.\n\nAny way, thanks for the explaining the virtue of git reset --merge.\n\njon.\n"},{"id":"140665","messageId":"20100429191150.GA10526@inner.home.ulmdo.de","threadId":"23632","inReplyTo":"20100428233758.GA1654@progeny.tock","subject":"git cherry(pick) dumps core","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2010-04-29T19:11:50Z","receivedAt":"2010-04-29T19:11:50Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"Hi,\n\nI just have a case of git cherry-pick dieing with a core dump.\nThe directly offending lines are get_message() in buildin/revert.c:\n\n\tif ((out->reencoded_message = reencode_string(raw_message,\n\t\t\t\t\tgit_commit_encoding, encoding)))\n\t\tout->message = out->reencoded_message;\n\n\tabbrev = find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV);\n\tabbrev_len = strlen(abbrev);\n\n\t/* Find beginning and end of commit subject. */\n\tp = out->message;\n\twhile (*p && (*p != '\\n' || p[1] != '\\n'))\n\nand out->message is null at that point.\n\nIt looks like reencode_string is returning NULL,\nand get_message can't quite cope with that.\n\nThis is in v1.7.1 (plus a few mods in git-daemon.c).\n\nI suppose it is a failing of iconv_open, as this is\non sparc SunOS 5.9, but the reaction is a bit harsh.\n\nUnfortunately the debugger is giving me strange\nresults, like:\n\n434 if (!in_encoding)\n(gdb) next\n436 conv = iconv_open(out_encoding, in_encoding);\n(gdb) print conv\n$3 = 0x1003f8\n(gdb) next\n437 if (conv == (iconv_t) -1)\n(gdb) print conv\n$4 = 0x1003f8\n(gdb) step\n474 }\n\nand the disasembly is just as counter-intuitive (with the branch targets).\n\nAndreas\n"},{"id":"140627","messageId":"20100429194936.GA31941@progeny.tock","threadId":"23632","inReplyTo":"20100429191150.GA10526@inner.home.ulmdo.de","subject":"Re: git cherry(pick) dumps core","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-29T19:49:36Z","receivedAt":"2010-04-29T19:49:36Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Andreas,\n\nAndreas Krey wrote:\n\n> I just have a case of git cherry-pick dieing with a core dump.\n> The directly offending lines are get_message() in buildin/revert.c:\n> \n> \tif ((out->reencoded_message = reencode_string(raw_message,\n> \t\t\t\t\tgit_commit_encoding, encoding)))\n> \t\tout->message = out->reencoded_message;\n> \n> \tabbrev = find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV);\n> \tabbrev_len = strlen(abbrev);\n> \n> \t/* Find beginning and end of commit subject. */\n> \tp = out->message;\n> \twhile (*p && (*p != '\\n' || p[1] != '\\n'))\n> \n> and out->message is null at that point.\n> \n> It looks like reencode_string is returning NULL,\n> and get_message can't quite cope with that.\n\nThanks for the report. What encoding were you using? (You can check\nwith ‘git cat-file commit ’.)\n\nThe code you mention was just wrong, sorry. If the local iconv\ndoesn’t understand some recording, the correct behavior is to pass the\nmessage through, not to segfault.\n\nWith this change, cherry-pick would treat the old message as UTF-8\n(or whatever the current [i18n] commitencoding setting specifies,\nif present). If the message happens to contain an illegal byte\nsequence, the cherry-pick will not segfault but it will still fail.\n\nIn other words, this patch should fix the segfault, but it does not\nfix the underlying problem which was there before.\n\ndiff --git a/builtin/revert.c b/builtin/revert.c\nindex bbaa937..9f8ceab 100644\n--- a/builtin/revert.c\n+++ b/builtin/revert.c\n@@ -114,6 +114,8 @@ static int get_message(const char *raw_message, struct commit_message *out)\n \tif ((out->reencoded_message = reencode_string(raw_message,\n \t\t\t\t\tgit_commit_encoding, encoding)))\n \t\tout->message = out->reencoded_message;\n+\telse\n+\t\tout->message = raw_message;\n \n \tabbrev = find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV);\n \tabbrev_len = strlen(abbrev);\n"},{"id":"140666","messageId":"20100429202139.GW10879@inner.home.ulmdo.de","threadId":"23632","inReplyTo":"20100429194936.GA31941@progeny.tock","subject":"Re: git cherry(pick) dumps core","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2010-04-29T20:21:39Z","receivedAt":"2010-04-29T20:21:39Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Thu, 29 Apr 2010 14:49:36 +0000, Jonathan Nieder wrote:\n> Hi Andreas,\n...\n> Thanks for the report. What encoding were you using? (You can check\n> with ???git cat-file commit ???.)\n\nActually, it was both UTF-8, both by the defaults in get_message():\n\nreencode_string (\n in=0x14d500 \"tree 97cea0f57e06e719c9e7e38c3fc17022048b4f38\\nparent 1ef1bb56e95284e683076f0d0cebe26e8ba02eca\\nauthor Andreas Krey 1272557698 +0200\\ncommitter Andreas Krey 1272557698 +02\"..., out_encoding=0x1003f8 \"UTF-8\", \n in_encoding=0x1003f8 \"UTF-8\") at utf8.c:434\n\nI'd guess that in that case, reencode_string wouldn't need to\nfire up iconv at all, and just copy the original string.\n\nThere being two different incarnations of iconv on this machine\nisn't making anything easier. :-( Will report when I find out\nwhat's wrong here. utf8 should be pretty universally known by now.\n\n> In other words, this patch should fix the segfault, but it does not\n> fix the underlying problem which was there before.\n\nI was wondering whether to be or not to be, er, to just use\nthe raw message or to die in this case.\n\nAndreas\n"},{"id":"140633","messageId":"20100430133228.GA1620@progeny.tock","threadId":"23632","inReplyTo":"20100429202139.GW10879@inner.home.ulmdo.de","subject":"Re: git cherry(pick) dumps core","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-30T13:32:29Z","receivedAt":"2010-04-30T13:32:29Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Andreas Krey wrote:\n> On Thu, 29 Apr 2010 14:49:36 +0000, Jonathan Nieder wrote:\n\n>> Thanks for the report. What encoding were you using? (You can check\n>> with ‘git cat-file commit ’.)\n>\n> Actually, it was both UTF-8, both by the defaults in get_message():\n[...]\n> There being two different incarnations of iconv on this machine\n> isn't making anything easier. :-( Will report when I find out\n> what's wrong here. utf8 should be pretty universally known by now.\n\nYes, the problem is that the to and from encodings match. I hadn’t\nrealized so before, but iconv doesn’t like that on some platforms\n(e.g., Solaris).\n\nSince this is the usual case, we should probably check for it like\ngit mailinfo does instead of waiting for iconv to fail.\n\nJonathan\n"},{"id":"141274","messageId":"20100508231729.GA6718@progeny.tock","threadId":"23632","inReplyTo":"20100430133228.GA1620@progeny.tock","subject":"[PATCH] cherry-pick: do not dump core when iconv fails","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-05-08T23:17:29Z","receivedAt":"2010-05-08T23:17:29Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"When cherry-picking, usually the new and old commit encodings are both\nUTF-8. Most old iconv implementations do not support this trivial\nconversion, so on old platforms, out->message remains NULL, and later\nattempts to read it segfault.\n\nFix this by noticing the input and output encodings match and skipping\nthe iconv step, like the other reencode_string() call sites already do.\nAlso stop segfaulting on other iconv failures: if iconv fails for some\nother reason, the best we can do is to pass the old message through.\n\nThis fixes a regression introduced in v1.7.1-rc0~15^2~2 (revert:\nclarify label on conflict hunks, 2010-03-20).\n\nReported-by: Andreas Krey \nSigned-off-by: Jonathan Nieder \n---\nAndreas reported this cherry-pick regression about a week ago, and a\npatch similar to this one seemed to fix it. The only question that\nmade me stall was what to do if iconv just doesn’t understand an\nencoding:\n\n - from a certain point of view it might make sense to pass through\n the message and note the old encoding\n\n - but on the other hand, that would not respect the user’s preference\n as expressed in i18n.commitencoding, and it would deny the caller\n the chance to fix the encoding problem in a text editor before\n commiting.\n\nThat second point was driven home when I tried to implement this: it\nrequired teaching ‘git commit’ to respect a new GIT_COMMIT_ENCODING\nvariable, but this was a pain (there is a sizeable amount of code\npaying attention to i18n.commitencoding) and the result would have\nbeen cherry-pick ignoring the $GIT_COMMIT_ENCODING preference,\ncreating encoding mismatches between ident and commit message to boot.\n\nEveryone should be using utf8 anyway. :)\n\nAnyway, this minimal fix should be safe (it just restores the old\nbehavior, except we do not use iconv for trivial conversions any\nmore). Patch is against v1.7.1-rc0~15^2~2.\n\nThanks to Andreas for the help.\n\n builtin/revert.c | 9 +++++++--\n 1 files changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/revert.c b/builtin/revert.c\nindex 5a5b721..5adaf27 100644\n--- a/builtin/revert.c\n+++ b/builtin/revert.c\n@@ -97,8 +97,13 @@ static int get_message(const char *raw_message, struct commit_message *out)\n \t\tencoding = \"UTF-8\";\n \tif (!git_commit_encoding)\n \t\tgit_commit_encoding = \"UTF-8\";\n-\tif ((out->reencoded_message = reencode_string(raw_message,\n-\t\t\t\t\tgit_commit_encoding, encoding)))\n+\n+\tout->reencoded_message = NULL;\n+\tout->message = raw_message;\n+\tif (strcmp(encoding, git_commit_encoding))\n+\t\tout->reencoded_message = reencode_string(raw_message,\n+\t\t\t\t\tgit_commit_encoding, encoding);\n+\tif (out->reencoded_message)\n \t\tout->message = out->reencoded_message;\n \n \tabbrev = find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV);\n-- \n1.7.1\n"},{"id":"141276","messageId":"7veihmaqyb.fsf@alter.siamese.dyndns.org","threadId":"23632","inReplyTo":"20100508231729.GA6718@progeny.tock","subject":"Re: [PATCH] cherry-pick: do not dump core when iconv fails","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-08T23:55:56Z","receivedAt":"2010-05-08T23:55:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> When cherry-picking, usually the new and old commit encodings are both\n> UTF-8. Most old iconv implementations do not support this trivial\n> conversion, so on old platforms, out->message remains NULL, and later\n> attempts to read it segfault.\n\nThis agrees with what builtin/commit.c does around ll.896; even if the\nencoding pair says \"utf8\" and \"UTF-8\", we would do the right thing.\n\nThanks.\n"}]}