{"thread":{"id":"6912","subject":"git-am failed, what's next ?","startedAt":"2007-02-22T08:22:27Z","lastAt":"2007-02-22T20:02:23Z","messageCount":10,"participants":["Francis Moreau","Andy Parkins","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"35218","messageId":"38b2ab8a0702220022wab25519hbb57629934e7f104@mail.gmail.com","threadId":"6912","inReplyTo":null,"subject":"git-am failed, what's next ?","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2007-02-22T08:22:27Z","receivedAt":"2007-02-22T08:22:27Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Hi,\n\nI'm a bit clueless when git-am failed to apply a patch. I dunno what I\nshould do at this point since errors reported by git-am are not\nusefull for me. For example I got:\n\n----\nerror: patch failed: foo:1\nerror: foo: patch does not apply\n\nPatch failed at 0001.\nWhen you have resolved this problem run \"git-am --resolved\".\nIf you would prefer to skip this patch, instead run \"git-am --skip\".\n---\n\nI know that git-am let some information in '.dotest' directory and\nthat I can find in it the plain patch file. I can use 'patch' command\nto apply it and see which part of the patch is conflicting. But I\nwould like to know if there are other ways to do it specially by using\ngit ?\n\nBTW, would it be possible to be more verbose when describing the error ?\n\nthanks\n-- \nFrancis\n\nPS: git rocks !\n"},{"id":"35221","messageId":"200702220848.06637.andyparkins@gmail.com","threadId":"6912","inReplyTo":"38b2ab8a0702220022wab25519hbb57629934e7f104@mail.gmail.com","subject":"Re: git-am failed, what's next ?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-22T08:48:05Z","receivedAt":"2007-02-22T08:48:05Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 February 22 08:22, Francis Moreau wrote:\n\n> ----\n> error: patch failed: foo:1\n> error: foo: patch does not apply\n>\n> Patch failed at 0001.\n> When you have resolved this problem run \"git-am --resolved\".\n> If you would prefer to skip this patch, instead run \"git-am --skip\".\n> ---\n\nI've often wished for more information from git-am (or more correctly, \ngit-apply).  However, you can sometimes get what you need to know another \nway.\n\n * First, make sure that your current tree is checked in so you can get back\n   to it easily.  Maybe switch to a new temporary branch to make it easy to\n   return to your current point.\n * Then run git-am to get the number of the failing patch, in your example \n   it's \"0001\"\n * Now, try and apply the patch manually, but turn on verbose and reject in \n   git-apply\n    $ git-apply --verbose --reject .dotest/0001\n   This is the only way I've found to get git to tell you which hunk of the\n   patch is being rejected.  Unfortunately, it will also leave you with that\n   patch partially applied.\n * Sometimes the partially applied patch will be enough.  Have a look at the\n   *.rej files that have been created and see if you can resolve the conflict\n   by hand - you could apply the patch by hand if it's only a small hunk.\n   If you do this, you can then continue with the git-am by first updating the \n   index (git-add somefile.c), then running git-am --resolved\n * If you wanted to you could just skip that patch with \"git-am --skip\"\n * If you wish you hadn't started any of this you can obviously use git-reset \n   to get you back to the start point.\n\nHope that helps.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"35223","messageId":"7v8xeqh6bj.fsf@assigned-by-dhcp.cox.net","threadId":"6912","inReplyTo":"38b2ab8a0702220022wab25519hbb57629934e7f104@mail.gmail.com","subject":"Re: git-am failed, what's next ?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-22T09:47:44Z","receivedAt":"2007-02-22T09:47:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"git-am\" deserves a section in the user-manual on its own.\nPerhaps the following can be massaged into JBF's User Manual,\nbut probably with copyediting and spellfixes.\n\nFirst, the basics.\n------------------\n\nWhen \"git am ./mbox\" stops in the middle, you will find\nthese files in the .dotest/ directory:\n\n0002 0003 0004...::\n\n        Numbered files are split e-mails, yet to be applied, and\n        the first one is the one that failed to apply.  Already\n        applied ones are removed so they may not begin with\n        0001.\n\nnext, last::\n\n        These files are used to control sequencing.  'next' is\n        the patch you are applying, and 'last' is the number of\n        the last patch in the series.\n\ninfo msg msg-clean final-commit patch::\n\n        These files record information of the patch you are\n        applying.  'info' lists the metainformation for the\n        commit to be made, 'msg' is the raw message extracted\n        from e-mail, 'msg-clean' is a copy of it after stripping\n        excess whitespaces, and 'final-commit' is after adding\n        sign-off lines (when -s is given).  'patch' is the patch\n        text itself.\n\nThere are two strategies to resume an \"am\" that stopped because\na patch does not apply.\n\nOne is to fix the patch into applicable shape in whatever way\nyou can think of, and attempt to apply it again, with \"git am\".\n\nThe other is to update your index to the desired state after\napplying the given patch in whatever way you can think of, and\ncontinue with \"git am --resolved\".\n\nYou can also choose not to continue, but skip one patch.  You\ncan say:\n\n\t$ git reset --hard\n        $ git am --skip\n\nto skip that particular patch.  This advances 'next' and\ncontinues with the remainder.\n\n[jc: I think that is not what you want in your RFH, but I am\nspelling it out for inclusion in the User Manual -- this comment\nitself should be removed if somebody wants to include this\nmessage to the manual.]\n\nNow, let's go on to \"whatever way you can think of\".\n\n\nFixing patch text\n-----------------\n\nLinus's way is to visit the ./mbox file in the editor, remove\nthe messages that have already been applied cleanly, edit the\noffending patch text to make it applicable.  Then:\n\n\t$ git reset --hard\n        $ rm -fr .dotest\n        $ git am edited-mailbox-file\n\nA variant of this approach is to edit .dotest/patch to make it\napplicable, and then say (without removing .dotest/ directory,\nof course):\n\n\t$ git am\n\nBut these are probably reserved for people who are comfortable\nediting the patch text.\n\n\nApplying by hand\n----------------\n\nIf you (as most people) are not comfortable editing the patch\ntext you can update your working tree to pretend that the patch\napplied cleanly.  You can do number of things:\n\n * Use \"git apply --index -C<n> .dotest/patch\" to attempt\n   applying the patch with reduced context.\n\n * Use \"git apply --reject .dotest/patch\" to get apply only\n   hunks that apply cleanly, while getting *.rej files.\n\n * Use \"GNU patch\" with less strict options, perhaps like\n\n\t$ patch -p1 --fuzz=<n> --ignore-whitespace\n\nWhatever you do, do not forget that your goal with this strategy\nis to prepare your index into a shape that the patch should have\nmade it into, if it applied cleanly.  In other words, after you\nare done, \"git diff --cached HEAD\" should produce what the\noriginal patch in .dotest/patch should have contained.  Also,\ntypically, \"git diff\" at that point should say nothing (unless\nyou know what you are doing).\n\nSo, if you used \"git apply\" without --index (or plain \"GNU\npatch\"), do not forget to \"git add\" to register the result in\nthe index.  Especially, if the patch adds a new file, do not\nforget to include it in the index!\n\nAfter you are done, you would continue with:\n\n\t$ git am --resolved\n\n\nLetting git work harder\n-----------------------\n\nIt _could_ be that the original submitter prepared the patch to\na different branch of your repository than the branch you are\ntrying to apply the patch to.  Sometimes I get a patch that is\nagainst my 'next' but the change does not depend on what is only\nin 'next' and should be applied to 'master' (or even 'maint').\nIf you have the pre-image blobs the patch was created against,\nand the patch was created with git and records \"index\" lines\nlike these correctly:\n\n        diff --git a/builtin-config.c b/builtin-config.c\n        index 0f9051d..f1433a4 100644\n\nthen you can tell git to fall back on 3-way merge to apply the\npatch.  After seeing \"git am ./mbox\" fail, you could try\n(without doing anything else):\n\n\t$ git am -3\n\nThis can result in one of three things:\n\n * It can complain, with \"Patch does not record usable index\n   information\".  When this happens, you are back to square-one.\n   Your repository does not have enough blobs for it to fall\n   back on 3-way merge.  The operation did not change anything\n   in your working tree nor what are in .dotest/ directory, so\n   it did not do any further harm.  You have to use one of the\n   two strategies described above instead.\n\n * It can successfully fall back on 3-way merge and cleanly\n   apply the patch.  Lucky you.\n\n * It can fall back on 3-way merge but the merge can conflict.\n\nIn the third case, the usual conflict resolution techniques you\nwould use during a conflicted merge applies, except that you do\nNOT conclude it with \"git commit\".\n\nThis \"3-way\" is in fact a variant of \"Applying by hand\"\nstrategy, and your goal is still to update the index into the\nshape the original patch should have made into.  After you\nresolve the conflict, you do \"git add\" the resolved path (or if\nthe patch is about removing a path and if you do want to remove\nthat path, then \"git rm\").  Make sure that \"git diff --cached\nHEAD\" output matches what you think .dotest/patch should have\ncontained.  Then:\n\n\t$ git am --resolved\n\nto continue.\n"},{"id":"35224","messageId":"38b2ab8a0702220209t33d78681gb260930069aa699b@mail.gmail.com","threadId":"6912","inReplyTo":"200702220848.06637.andyparkins@gmail.com","subject":"Re: git-am failed, what's next ?","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2007-02-22T10:09:18Z","receivedAt":"2007-02-22T10:09:18Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Hi,\n\nOn 2/22/07, Andy Parkins <andyparkins@gmail.com> wrote:\n> I've often wished for more information from git-am (or more correctly,\n> git-apply).  However, you can sometimes get what you need to know another\n> way.\n>\n\nit seems pretty the same flow that I'm used to doing except that I\nused 'patch' instead of 'git-apply'...\n\n>  * First, make sure that your current tree is checked in so you can get back\n>    to it easily.  Maybe switch to a new temporary branch to make it easy to\n>    return to your current point.\n>  * Then run git-am to get the number of the failing patch, in your example\n>    it's \"0001\"\n>  * Now, try and apply the patch manually, but turn on verbose and reject in\n>    git-apply\n>     $ git-apply --verbose --reject .dotest/0001\n>    This is the only way I've found to get git to tell you which hunk of the\n>    patch is being rejected.  Unfortunately, it will also leave you with that\n>    patch partially applied.\n\nhm, I actually used 'patch' instead because I wasn't aware of\n'--reject' option. The default behaviour is different, and I'm not\nsure to know why...\n\nObviously I really should play with it.\n\n> Hope that helps.\n\nthanks\n-- \nFrancis\n"},{"id":"35226","messageId":"38b2ab8a0702220238l14628f54s3165f050f6af5447@mail.gmail.com","threadId":"6912","inReplyTo":"7v8xeqh6bj.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-am failed, what's next ?","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2007-02-22T10:38:51Z","receivedAt":"2007-02-22T10:38:51Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Hi,\n\nJunio C Hamano wrote:\n> \"git-am\" deserves a section in the user-manual on its own.\n> Perhaps the following can be massaged into JBF's User Manual,\n> but probably with copyediting and spellfixes.\n>\n\nyes it's definitly something useful for me. Thanks for writing it !\n\n> First, the basics.\n> ------------------\n>\n> When \"git am ./mbox\" stops in the middle, you will find\n> these files in the .dotest/ directory:\n>\n\n[snip]\n\n> There are two strategies to resume an \"am\" that stopped because\n> a patch does not apply.\n>\n> One is to fix the patch into applicable shape in whatever way\n> you can think of, and attempt to apply it again, with \"git am\".\n>\n> The other is to update your index to the desired state after\n> applying the given patch in whatever way you can think of, and\n> continue with \"git am --resolved\".\n>\n> You can also choose not to continue, but skip one patch.  You\n> can say:\n>\n> \t$ git reset --hard\n>         $ git am --skip\n>\n> to skip that particular patch.  This advances 'next' and\n> continues with the remainder.\n>\n> [jc: I think that is not what you want in your RFH, but I am\n> spelling it out for inclusion in the User Manual -- this comment\n> itself should be removed if somebody wants to include this\n> message to the manual.]\n>\n\nnope, and this is quite well explained in the man page.\n\n> Now, let's go on to \"whatever way you can think of\".\n>\n>\n> Fixing patch text\n> -----------------\n>\n> Linus's way is to visit the ./mbox file in the editor, remove\n> the messages that have already been applied cleanly, edit the\n> offending patch text to make it applicable.  Then:\n>\n> \t$ git reset --hard\n>         $ rm -fr .dotest\n>         $ git am edited-mailbox-file\n>\n> A variant of this approach is to edit .dotest/patch to make it\n> applicable, and then say (without removing .dotest/ directory,\n> of course):\n>\n> \t$ git am\n>\n> But these are probably reserved for people who are comfortable\n> editing the patch text.\n>\n\ndefinitely not my case...\n\n>\n> Applying by hand\n> ----------------\n>\n> If you (as most people) are not comfortable editing the patch\n> text you can update your working tree to pretend that the patch\n> applied cleanly.  You can do number of things:\n>\n>  * Use \"git apply --index -C<n> .dotest/patch\" to attempt\n>    applying the patch with reduced context.\n>\n>  * Use \"git apply --reject .dotest/patch\" to get apply only\n>    hunks that apply cleanly, while getting *.rej files.\n>\n>  * Use \"GNU patch\" with less strict options, perhaps like\n>\n> \t$ patch -p1 --fuzz=<n> --ignore-whitespace\n>\n\nwhy using 'patch' ? couldn't this be done by using 'git-apply' ?\n\nMaybe these several choices could be proposed to the user when using\nthe interactive mode ?\n\n>\n>\n> Letting git work harder\n> -----------------------\n>\n\n[snip]\n\n> This \"3-way\" is in fact a variant of \"Applying by hand\"\n> strategy, and your goal is still to update the index into the\n> shape the original patch should have made into.  After you\n> resolve the conflict, you do \"git add\" the resolved path (or if\n> the patch is about removing a path and if you do want to remove\n> that path, then \"git rm\").  Make sure that \"git diff --cached\n> HEAD\" output matches what you think .dotest/patch should have\n> contained.  Then:\n>\n> \t$ git am --resolved\n>\n> to continue.\n>\n\nThis part is really interesting.\n-- \nFrancis\n"},{"id":"35227","messageId":"38b2ab8a0702220250v2c2ca77fub95b1e9a2a57bd78@mail.gmail.com","threadId":"6912","inReplyTo":"7v8xeqh6bj.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-am failed, what's next ?","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2007-02-22T10:50:02Z","receivedAt":"2007-02-22T10:50:02Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> \t$ git am -3\n>\n> This can result in one of three things:\n>\n>  * It can complain, with \"Patch does not record usable index\n>    information\".  When this happens, you are back to square-one.\n>    Your repository does not have enough blobs for it to fall\n>    back on 3-way merge.  The operation did not change anything\n>    in your working tree nor what are in .dotest/ directory, so\n>    it did not do any further harm.  You have to use one of the\n>    two strategies described above instead.\n>\n\nBTW, in this case I got the following error message:\n\nfatal: sha1 information is lacking or useless (foo).\nPatch does not record usable index information.\nCannot fall back to three-way merge.\nPatch failed at 0001.\n\nwhich is hard to understand, whereas your explanation:\n\nYour repository does not have enough blobs for it to fall\nback on 3-way merge.\n\nsounds better and easier to understand to me...\n-- \nFrancis\n"},{"id":"35228","messageId":"200702221113.44338.andyparkins@gmail.com","threadId":"6912","inReplyTo":"7v8xeqh6bj.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-am failed, what's next ?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-22T11:13:42Z","receivedAt":"2007-02-22T11:13:42Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 February 22 09:47, Junio C Hamano wrote:\n\n> If you have the pre-image blobs the patch was created against,\n> and the patch was created with git and records \"index\" lines\n> like these correctly:\n>\n>         diff --git a/builtin-config.c b/builtin-config.c\n>         index 0f9051d..f1433a4 100644\n>\n> then you can tell git to fall back on 3-way merge to apply the\n> patch.  After seeing \"git am ./mbox\" fail, you could try\n\nMagic.  I had no idea about this.  Could it be made even more magical by doing \nthis for you?\n\ngit-am would know if the patch that failed is a git-generated patch, so when \nthings go wrong, before bombing out it could try a 3-way merge.  It's much \neasier to resolve faults with the usual conflict markers than reading \npatches.  It's also possible that the 3-way merge will succeed and git-am \nwill continue without ever needing to worry the user.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"35249","messageId":"Pine.LNX.4.63.0702222009380.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6912","inReplyTo":"38b2ab8a0702220022wab25519hbb57629934e7f104@mail.gmail.com","subject":"Re: git-am failed, what's next ?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-22T19:11:21Z","receivedAt":"2007-02-22T19:11:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Feb 2007, Francis Moreau wrote:\n\n> I'm a bit clueless when git-am failed to apply a patch. I dunno what I\n> should do at this point since errors reported by git-am are not\n> usefull for me. For example I got:\n> \n> ----\n> error: patch failed: foo:1\n> error: foo: patch does not apply\n\nI had that quite often. I then ran\n\n\tgit apply --verbose < .dotest/patch\n\nto find out why it fails, but alas it did not tell me more. That's why I \nwrote this patch:\n\n-- snipsnap --\n[PATCH] apply: make --verbose a little more useful\n\nWhen a patch fails, I automatically add '-v' to the command line\nto see what fails.\n\nThis patch makes -v a synonym to --verbose, and actually tells\nthe user which text was not found.\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n---\n builtin-apply.c |    7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex 630d8fd..2dde341 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -1723,6 +1723,8 @@ static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag, i\n \t\t\t/* Ignore it, we already handled it */\n \t\t\tbreak;\n \t\tdefault:\n+\t\t\tif (apply_verbosely)\n+\t\t\t\terror(\"invalid start of line: '%c'\", first);\n \t\t\treturn -1;\n \t\t}\n \t\tpatch += len;\n@@ -1820,6 +1822,9 @@ static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag, i\n \t\t}\n \t}\n \n+\tif (offset && apply_verbosely)\n+\t\terror(\"while searching for:\\n%.*s\", oldsize, oldlines);\n+\n \tfree(old);\n \tfree(new);\n \treturn offset;\n@@ -2811,7 +2816,7 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)\n \t\t\tapply = apply_with_reject = apply_verbosely = 1;\n \t\t\tcontinue;\n \t\t}\n-\t\tif (!strcmp(arg, \"--verbose\")) {\n+\t\tif (!strcmp(arg, \"-v\") || !strcmp(arg, \"--verbose\")) {\n \t\t\tapply_verbosely = 1;\n \t\t\tcontinue;\n \t\t}\n-- \n1.5.0.51.ge5582-dirty\n"},{"id":"35253","messageId":"7virduf0s1.fsf@assigned-by-dhcp.cox.net","threadId":"6912","inReplyTo":"38b2ab8a0702220238l14628f54s3165f050f6af5447@mail.gmail.com","subject":"Re: git-am failed, what's next ?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-22T19:30:22Z","receivedAt":"2007-02-22T19:30:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Francis Moreau\" <francis.moro@gmail.com> writes:\n\n>> Applying by hand\n>> ----------------\n>>\n>> If you (as most people) are not comfortable editing the patch\n>> text you can update your working tree to pretend that the patch\n>> applied cleanly.  You can do number of things:\n>>\n>>  * Use \"git apply --index -C<n> .dotest/patch\" to attempt\n>>    applying the patch with reduced context.\n>>\n>>  * Use \"git apply --reject .dotest/patch\" to get apply only\n>>    hunks that apply cleanly, while getting *.rej files.\n>>\n>>  * Use \"GNU patch\" with less strict options, perhaps like\n>>\n>> \t$ patch -p1 --fuzz=<n> --ignore-whitespace\n>\n> why using 'patch' ? couldn't this be done by using 'git-apply' ?\n\nThe default operationg mode of 'patch' is less strict than\ngit-apply is, and it can be told to be much less strict, so some\npeople seem to like it.  You do not have to use it unless your\npatch text is based on too far away version.  I usually don't.\n\nAlso the above is not an exhaustive list.  If you are handy with\nother tools to make patches that do not cleanly apply apply\n(e.g. wiggle), they can be used instead.\n\n> Maybe these several choices could be proposed to the user when using\n> the interactive mode ?\n\nI do not think so.  As far as I remember, interactive mode\nhelps the \"Fixing patch text\" strategy but not \"Applying by\nhand\" strategy.  When a patch does not apply, you fix the text\nand re-apply, and [v]iew command is to review how you fixed the\npatch, for example.\n"},{"id":"35256","messageId":"7v3b4yezao.fsf@assigned-by-dhcp.cox.net","threadId":"6912","inReplyTo":"200702221113.44338.andyparkins@gmail.com","subject":"Re: git-am failed, what's next ?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-22T20:02:23Z","receivedAt":"2007-02-22T20:02:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> On Thursday 2007 February 22 09:47, Junio C Hamano wrote:\n>\n>> If you have the pre-image blobs the patch was created against,\n>> and the patch was created with git and records \"index\" lines\n>> like these correctly:\n>>\n>>         diff --git a/builtin-config.c b/builtin-config.c\n>>         index 0f9051d..f1433a4 100644\n>>\n>> then you can tell git to fall back on 3-way merge to apply the\n>> patch.  After seeing \"git am ./mbox\" fail, you could try\n>\n> Magic.  I had no idea about this.  Could it be made even more\n> magical by doing this for you?\n\nYou can start with --3way from the beginning, not just after\nseeing it fail.\n\nIn the earlier description, I made it sound as if \"-3\" is an\noption for recovery, but that is not the case.\n\nRunning \"git am\" without mbox parameter and an existing .dotest/\nis the instruction for \"git am\" to continue, and the first thing\nit does when told to continue is different depending on if\neither --skip or --resolved is given.  --skip makes it skip the\npatch.  --resolved takes the index, uses the metainfo to make a\ncommit.  Lack of these options makes it re-try the one recorded\nin .dotest/next file.  After that, if it fails (and --skip would\nnot fail), it stops.  Otherwise it goes on to the next patch.\n\nThe example you referred to as \"magic\" is just a normal \"retry it\"\ncodepath but running with the \"--3way\" option.\n\nThe 3-way fallback is not enabled by default.  A minor reason\nfor this is that it did not exist in the original and is an\noptional feature that was added later on.\n\nBut the real reason is that as a principle, git tools err on the\nsafe side by default, just like our use of \"git-apply\" in\n\"git-am\" does not allow fuzz in the patch nor reducing context\nby default for strictness.  That way, the patch application\nprocess is stopped and gives the non-interactive user a chance\nto inspect _why_ the patch does not apply, before deciding to\ncontinue, either with fuzz'ed patch application, fixing the\npatch text, or falling back on 3-way.\n\nBut these days, I almost always run:\n\n\t$ git am -3 -s ./mbox\n\nand inspect the ones that actually used 3-way fallback after the\nfact.  It _might_ make sense to add a configuration option to\ndefault to -3 (or -s for that matter), like:\n\n\t[am]\n\t\tsignoff\n                threeway\n\nand do something like this:\n\n---\n git-am.sh |   14 ++++++++++++++\n 1 files changed, 14 insertions(+), 0 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex 6db9cb5..c0395f5 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -109,6 +109,7 @@ prec=4\n dotest=.dotest sign= utf8=t keep= skip= interactive= resolved= binary= resolvemsg=\n git_apply_opt=\n \n+has_opt=\n while case \"$#\" in 0) break;; esac\n do\n \tcase \"$1\" in\n@@ -155,8 +156,21 @@ do\n \t*)\n \tbreak ;;\n \tesac\n+\thas_opt=t\n done\n \n+if test -z \"$has_opt\"\n+then\n+\tif test true = \"$(git config --bool am.signoff)\"\n+\tthen\n+\t\tsign=t\n+\tfi\n+\tif test true = \"$(git config --bool am.threeway)\"\n+\tthen\n+\t\tthreeway=t\n+\tfi\n+fi\n+\n # If the dotest directory exists, but we have finished applying all the\n # patches in them, clear it out.\n if test -d \"$dotest\" &&\n"}]}