{"thread":{"id":"26516","subject":"Aborting cherry-pick","startedAt":"2011-02-16T09:16:28Z","lastAt":"2011-02-19T20:13:10Z","messageCount":5,"participants":["Piotr Krukowiecki","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"161271","messageId":"AANLkTingcnvm6rLnWdweAKdeOWAVjh+F+6BMWzfJxhKi@mail.gmail.com","threadId":"26516","inReplyTo":null,"subject":"Aborting cherry-pick","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-02-16T09:16:28Z","receivedAt":"2011-02-16T09:16:28Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"Hi,\n\nI'd like to suggest improving cherry-pick messages/documentation\nin case of conflicts.\n\nExample of cherry-pick conflict:\n\n   $ git cherry-pick  c64e8caa56fd76577bbaea37592f4a9df10ab1b8\n   error: could not apply c64e8ca... <<commit message>>\n   hint: after resolving the conflicts, mark the corrected paths\n   hint: with 'git add <paths>' or 'git rm <paths>'\n\n   $ git status\n   # On branch master\n   # Unmerged paths:\n   #   (use \"git reset HEAD <file>...\" to unstage)\n   #   (use \"git add/rm <file>...\" as appropriate to mark resolution)\n   #\n   #\tboth modified:      <<file>>\n   #\n   no changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nI see following possibilities:\n\n1. add hint to cherry-pick how to abort merge, for example:\n   hint: use 'git reset --merge ORIG_HEAD' to abort merge\n\n2. add hint to status how to abort merge, for example:\n   #   (use 'git reset --merge ORIG_HEAD' to abort merge)\n\n3. add \"--abort\" to cherry-pick (same option as for git-merge)\n\nThe ORIG_HEAD is specified in man page example. There is also\na possibility of omitting ORIG_HEAD in which case local changes\nare retained. Maybe this is a better suggesting for the user?\nOr maybe describe both cases somewhere and point user to this\ndocumentation in status/cherry-pick output?\n\ngit-cherry-pick uses word \"cancel\" in man page (in example) and\ngit-merge uses word \"abort\" for (as I understand) the same action.\n\nI would suggest using either same word for both cases, or using both\nwords in both cases. Otherwise it's confusing if you read about \"aborting\"\nmerges and when you want to abort cherry-pick you don't find it - because\nit's called \"canceling\".\n\n\nWhat is your opinion on this?\n\n\n-- \nPiotrek\n"},{"id":"161486","messageId":"20110218012435.GA16893@elie","threadId":"26516","inReplyTo":"AANLkTingcnvm6rLnWdweAKdeOWAVjh+F+6BMWzfJxhKi@mail.gmail.com","subject":"[PATCH] cherry-pick: when pick fails, explain how to cancel","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-18T01:24:35Z","receivedAt":"2011-02-18T01:24:35Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"If you tried a cherry-pick or revert resulting in complex conflicts\nand want to start over, \"git reset --merge HEAD\" might help.\n\nRequested-by: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>\nSigned-off-by: Jonathan Nieder <jrnieder@gmail.com>\n---\n(+cc some relevant people. Johan wrote merge --abort, Jay is adding\na status hint during cherry-pick, Christian wrote reset --merge and\nmuch related cherry-pick functionality)\n\nPiotr Krukowiecki wrote:\n\n> Example of cherry-pick conflict:\n>\n>    $ git cherry-pick  c64e8caa56fd76577bbaea37592f4a9df10ab1b8\n>    error: could not apply c64e8ca... <<commit message>>\n>    hint: after resolving the conflicts, mark the corrected paths\n>    hint: with 'git add <paths>' or 'git rm <paths>'\n>\n>    $ git status\n>    # On branch master\n>    # Unmerged paths:\n[...]\n> I see following possibilities:\n>\n> 1. add hint to cherry-pick how to abort merge, for example:\n>    hint: use 'git reset --merge ORIG_HEAD' to abort merge\n\nGood idea.  \"git cherry-pick\" does not set ORIG_HEAD, so I\nput \"git reset --merge HEAD\" instead.\n\n> 2. add hint to status how to abort merge, for example:\n>    #   (use 'git reset --merge ORIG_HEAD' to abort merge)\n\n\"git reset --merge\" will remove local changes marked with \"git add\",\nunder the assumption that they were part of the conflict resolution\nand thus should be cleared away.\n\nThis leaves me afraid of the following scenario:\n\n\tgit pull\n\t# conflict?  agh!\n\n\t# ... two days later ...\n\t... hack hack hack ...\n\t... add add add ...\n\tgit commit;\t# fails because of unmerged files\n\n\t# whoops, forgot about that merge.\n\t# Let's do what it says to do:\n\tgit reset --merge ORIG_HEAD\n\nIt seems safest to only recommend \"reset --merge\" immediately\nafter a mergy operation.\n\n> The ORIG_HEAD is specified in man page example.\n\nI assume you mean on the git-reset page?  It might be nice to add\nmore examples and to update the current ones with current best\npractice (e.g., using reset --keep more often).\n\nThe use of ORIG_HEAD there also allows the following:\n\n\tgit pull\n\t# success?  But I didn't want that\n\tgit reset --merge ORIG_HEAD\n\nand protects against situations in which ORIG_HEAD is not present\n(though merge --abort does that better, I think).\n\n> git-cherry-pick uses word \"cancel\" in man page (in example) and\n> git-merge uses word \"abort\" for (as I understand) the same action.\n\nHmm, where is this example in the cherry-pick manpage?\n\nThanks for the suggestions.  Generally speaking, I like them.\n\n builtin/revert.c |    4 +++-\n 1 files changed, 3 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/revert.c b/builtin/revert.c\nindex dc1b702..78baae7 100644\n--- a/builtin/revert.c\n+++ b/builtin/revert.c\n@@ -267,11 +267,13 @@ static void print_advice(void)\n \t}\n \n \tadvise(\"after resolving the conflicts, mark the corrected paths\");\n-\tadvise(\"with 'git add <paths>' or 'git rm <paths>'\");\n+\tadvise(\"with 'git add <paths>' and 'git rm <paths>'\");\n \n \tif (action == CHERRY_PICK)\n \t\tadvise(\"and commit the result with 'git commit -c %s'\",\n \t\t       find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV));\n+\n+\tadvise(\"or use 'git reset --merge HEAD' to abort\");\n }\n \n static void write_message(struct strbuf *msgbuf, const char *filename)\n-- \n1.7.4.1\n"},{"id":"161564","messageId":"4D5EE6BB.9070507@gmail.com","threadId":"26516","inReplyTo":"20110218012435.GA16893@elie","subject":"Re: [PATCH] cherry-pick: when pick fails, explain how to cancel","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-02-18T21:38:03Z","receivedAt":"2011-02-18T21:38:03Z","isPatch":true,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"W dniu 18.02.2011 02:24, Jonathan Nieder pisze:\n> Piotr Krukowiecki wrote:\n>> 1. add hint to cherry-pick how to abort merge, for example:\n>>    hint: use 'git reset --merge ORIG_HEAD' to abort merge\n> \n> Good idea.  \"git cherry-pick\" does not set ORIG_HEAD, so I\n> put \"git reset --merge HEAD\" instead.\n\nYou're right. I was sure I have tested it, but when I try to \nuse ORIG_HEAD now it does not work.\n\nI took it from Documentation/git-cherry-pick.txt, which seem\nto be wrong:\n\n   $ git cherry-pick topic^             <1>\n   $ git diff                           <2>\n   $ git reset --merge ORIG_HEAD        <3>\n   [...]\n   <3> cancel the cherry-pick.  In other words, return to the\n   pre-cherry-pick state, preserving any local modifications you had in\n   the working tree.\n\n\n>> 2. add hint to status how to abort merge, for example:\n>>    #   (use 'git reset --merge ORIG_HEAD' to abort merge)\n> \n> \"git reset --merge\" will remove local changes marked with \"git add\",\n> under the assumption that they were part of the conflict resolution\n> and thus should be cleared away.\n\nDidn't know that (one probably shouldn't merge with uncommitted/local\nchanges anyway). git-reset.txt mentions it, but there's no explicit\nwarning.\n\n\n> This leaves me afraid of the following scenario:\n> \n> \tgit pull\n> \t# conflict?  agh!\n> \n> \t# ... two days later ...\n> \t... hack hack hack ...\n> \t... add add add ...\n> \tgit commit;\t# fails because of unmerged files\n> \n> \t# whoops, forgot about that merge.\n> \t# Let's do what it says to do:\n> \tgit reset --merge ORIG_HEAD\n> \n> It seems safest to only recommend \"reset --merge\" immediately\n> after a mergy operation.\n\nIs it possible to recognize that you have something more than what\nwas cause by the merge/cherry-pick?\n\n\n>> The ORIG_HEAD is specified in man page example.\n> \n> I assume you mean on the git-reset page?  It might be nice to add\n> more examples and to update the current ones with current best\n> practice (e.g., using reset --keep more often).\n\nYes, it says:\n\n   Running \"git reset --hard ORIG_HEAD\" will let you go back to where\n   you were, but it will discard your local changes, which you do not\n   want.  \"git reset --merge\" keeps your local changes.\n\n \n>> git-cherry-pick uses word \"cancel\" in man page (in example) and\n>> git-merge uses word \"abort\" for (as I understand) the same action.\n> \n> Hmm, where is this example in the cherry-pick manpage?\n\nIt's in the Documentation/cherry-pick.txt (in current master). I assume \nman pages are generated from those text files. I have also cited it at \nthe beginning of this mail.\n\n\n-- \nPiotr Krukowiecki\n"},{"id":"161567","messageId":"20110218231748.GA17836@elie","threadId":"26516","inReplyTo":"4D5EE6BB.9070507@gmail.com","subject":"[PATCH] Documentation: cherry-pick does not set ORIG_HEAD","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-18T23:17:48Z","receivedAt":"2011-02-18T23:17:48Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"The example that uses \"reset --merge\" to bail out from a failed\ncherry-pick is dangerously wrong.  For example,\n\n\tgit reset --keep master\n\tgit cherry-pick HEAD@{1};\t# conflicts!\n\tgit reset --merge ORIG_HEAD;\t# let's try that again\n\tgit cherry-pick --strategy=more-careful HEAD@{1}\n\nwould not reset the topic to the pre cherry-pick state (master) but to\nwhatever branch we were on before then.\n\nThe example used ORIG_HEAD by habit from aborting merges.  \"git reset\n--merge HEAD\" is more appropriate here.\n\nNoticed-by: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>\nSigned-off-by: Jonathan Nieder <jrnieder@gmail.com>\n---\nPiotr Krukowiecki wrote:\n\n> I took it from Documentation/git-cherry-pick.txt, which seem\n> to be wrong:\n\nGood catch.  The manpage I was looking at was stale.\n\n>> \"git reset --merge\" will remove local changes marked with \"git add\",\n>> under the assumption that they were part of the conflict resolution\n>> and thus should be cleared away.\n>\n> Didn't know that (one probably shouldn't merge with uncommitted/local\n> changes anyway). git-reset.txt mentions it, but there's no explicit\n> warning.\n\nCare to write a patch?\n\n>> This leaves me afraid of the following scenario:\n>>\n[...]\n>> \t# ... two days later ...\n>> \t... hack hack hack ...\n>> \t... add add add ...\n>> \tgit commit;\t# fails because of unmerged files\n>> \n>> \t# whoops, forgot about that merge.\n>> \t# Let's do what it says to do:\n>> \tgit reset --merge ORIG_HEAD\n[...]\n> Is it possible to recognize that you have something more than what\n> was cause by the merge/cherry-pick?\n\nI suppose it depends what you mean.  I see at least two distinct\nproblems to solve:\n\n A. \"undo\" facility to recover from an ugly cherry-pick\n\nThis one is what reset --merge is for.  The idea is that after\nspending a little while trying to make something good out of a\nmess, you say, \"oh, bother, let me get back to where I started\".\n\nSo in this case it really does make sense to back out any changes\nyou marked with \"git add\" after the cherry-pick, since they were\npart of the messy resolution process.  If there had been any\nchanges registered before the cherry-pick, the cherry-pick would\nhave just failed without making a mess.\n\nA patch in flight makes \"git cherry-pick\" print advice for this case\nwhen it encounters conflicts (thanks!).\n\n B. clearing away a forgotten merge from long ago\n\nIf you had been doing work without remembering that there was\na merge in progress, the best way to recover is probably a plain\n\"git reset HEAD -- .\".\n\nThis is a case people might be looking for advice about when reading\n\"git status\" (\"where was I?\") output.\n\nThanks.\n\n Documentation/git-cherry-pick.txt |    6 +-\n t/t3404-rebase-interactive.sh     |    6 --\n t/t3510-cherry-pick-doc.sh        |  137 +++++++++++++++++++++++++++++++++++++\n t/test-lib.sh                     |    9 +++\n 4 files changed, 149 insertions(+), 9 deletions(-)\n create mode 100755 t/t3510-cherry-pick-doc.sh\n\ndiff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt\nindex 749d68a..abedcb7 100644\n--- a/Documentation/git-cherry-pick.txt\n+++ b/Documentation/git-cherry-pick.txt\n@@ -137,7 +137,7 @@ again, this time exercising more care about matching up context lines.\n ------------\n $ git cherry-pick topic^             <1>\n $ git diff                           <2>\n-$ git reset --merge ORIG_HEAD        <3>\n+$ git reset --merge HEAD             <3>\n $ git cherry-pick -Xpatience topic^  <4>\n ------------\n <1> apply the change that would be shown by `git show topic^`.\n@@ -146,8 +146,8 @@ information about the conflict is written to the index and\n working tree and no new commit results.\n <2> summarize changes to be reconciled\n <3> cancel the cherry-pick.  In other words, return to the\n-pre-cherry-pick state, preserving any local modifications you had in\n-the working tree.\n+pre-cherry-pick state, preserving any local modifications you have\n+in the working tree.\n <4> try to apply the change introduced by `topic^` again,\n spending extra time to avoid mistakes based on incorrectly matching\n context lines.\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex 7d8147b..88f1192 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -29,12 +29,6 @@ Initial setup:\n \n . \"$TEST_DIRECTORY\"/lib-rebase.sh\n \n-test_cmp_rev () {\n-\tgit rev-parse --verify \"$1\" >expect.rev &&\n-\tgit rev-parse --verify \"$2\" >actual.rev &&\n-\ttest_cmp expect.rev actual.rev\n-}\n-\n set_fake_editor\n \n # WARNING: Modifications to the initial repository can change the SHA ID used\ndiff --git a/t/t3510-cherry-pick-doc.sh b/t/t3510-cherry-pick-doc.sh\nnew file mode 100755\nindex 0000000..e645caa\n--- /dev/null\n+++ b/t/t3510-cherry-pick-doc.sh\n@@ -0,0 +1,137 @@\n+#!/bin/sh\n+\n+test_description='examples from git-cherry-pick(1)\n+\n+Check that what the manual claims is still true.\n+\n+  -\n+  + seven [next]\n+  + six\n+  + five [master]\n+  + four\n+  + three\n+  + two (modifies one.t)\n+  + one\n+  + initial\n+'\n+. ./test-lib.sh\n+\n+check_log () {\n+\tgit rev-list \"$2\" |\n+\tgit diff-tree -r --root --stdin |\n+\tsed -e \"s/$_x40/OBJID/g\" >actual.log &&\n+\ttest_cmp \"$1\" actual.log\n+}\n+\n+test_expect_success setup '\n+\tGIT_EDITOR=false &&\n+\texport GIT_EDITOR &&\n+\n+\ttest_commit initial &&\n+\ttest_commit one &&\n+\ttest_commit two one.t &&\n+\ttest_commit three &&\n+\ttest_commit four &&\n+\ttest_commit five &&\n+\tgit checkout -b next &&\n+\ttest_commit six &&\n+\ttest_commit seven &&\n+\tgit checkout -b topic initial\n+'\n+\n+test_expect_success 'cherry-pick tip of branch' '\n+\tcat >expect.log <<-\\EOF &&\n+\tOBJID\n+\t:000000 100644 OBJID OBJID A\tfive.t\n+\tEOF\n+\tgit reset --hard initial &&\n+\tgit cherry-pick master &&\n+\tcheck_log expect.log initial..topic\n+'\n+\n+test_expect_success 'cherry-pick to catch up' '\n+\tcat >expect.log <<-\\EOF &&\n+\tOBJID\n+\t:000000 100644 OBJID OBJID A\tfive.t\n+\tOBJID\n+\t:000000 100644 OBJID OBJID A\tfour.t\n+\tOBJID\n+\t:000000 100644 OBJID OBJID A\tthree.t\n+\tOBJID\n+\t:100644 100644 OBJID OBJID M\tone.t\n+\tOBJID\n+\t:000000 100644 OBJID OBJID A\tone.t\n+\tEOF\n+\tgit reset --hard initial &&\n+\tgit cherry-pick ..master &&\n+\tcheck_log expect.log initial..topic &&\n+\n+\tgit reset --hard initial &&\n+\tgit cherry-pick ^HEAD master &&\n+\tcheck_log expect.log initial..topic\n+'\n+\n+test_expect_success 'cherry-pick selected changes' '\n+\tcat >expect.log <<-\\EOF &&\n+\tOBJID\n+\t:000000 100644 OBJID OBJID A\tthree.t\n+\tOBJID\n+\t:000000 100644 OBJID OBJID A\tone.t\n+\tEOF\n+\tgit reset --hard initial &&\n+\tgit cherry-pick master~4 master~2 &&\n+\tcheck_log expect.log initial..topic\n+'\n+\n+test_expect_success 'cherry-pick --no-commit' '\n+\t>expect.log &&\n+\tcat >expect.after-commit <<-\\EOF &&\n+\tOBJID\n+\t:000000 100644 OBJID OBJID A\tfour.t\n+\t:000000 100644 OBJID OBJID A\tseven.t\n+\tEOF\n+\tgit reset --hard initial &&\n+\tgit cherry-pick -n master~1 next &&\n+\tcheck_log expect.log initial..topic &&\n+\ttest_must_fail git commit &&\n+\tgit commit -m \"squashed patches\" &&\n+\tcheck_log expect.after-commit initial..topic\n+'\n+\n+test_expect_success 'cherry-pick --ff' '\n+\tgit reset --hard initial &&\n+\tgit cherry-pick --ff ..next &&\n+\ttest_cmp_rev next topic\n+'\n+\n+test_expect_success 'cherry-pick --no-commit --stdin' '\n+\tgit reset --hard initial &&\n+\tgit rev-list --reverse master -- one.t |\n+\tgit cherry-pick -n --stdin &&\n+\n+\ttest_cmp_rev initial topic &&\n+\tgit diff-index --cached --exit-code master -- one.t &&\n+\tgit rm -f one.t &&\n+\tgit diff-index --cached --exit-code initial\n+'\n+\n+test_expect_success 'cherry-pick -Xignore-all-space' '\n+\tgit reset --hard one &&\n+\ttest_commit one-with-whitespace one.t \"   one   \" &&\n+\n+\ttest_must_fail git cherry-pick three^ &&\n+\tgit diff >conflict-desc &&\n+\tgrep \"[+][+]<<<\" conflict-desc &&\n+\n+\techo modified >initial.t &&\n+\tgit reset --merge HEAD &&\n+\ttest_cmp_rev one-with-whitespace topic &&\n+\ttest_must_fail git diff --exit-code HEAD &&\n+\techo initial >initial.t &&\n+\tgit diff --exit-code HEAD &&\n+\n+\tgit cherry-pick -Xignore-all-space three^ &&\n+\tgit diff --exit-code two topic\n+'\n+\n+test_done\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 0fdc541..0c053b3 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -673,6 +673,15 @@ test_line_count () {\n \tfi\n }\n \n+# test_cmp_rev checks that two revision specifiers refer to the\n+# same object.  Uses expect.rev and actual.rev files in the\n+# current directory as scratch space.\n+test_cmp_rev () {\n+\tgit rev-parse --verify \"$1\" >expect.rev &&\n+\tgit rev-parse --verify \"$2\" >actual.rev &&\n+\ttest_cmp expect.rev actual.rev\n+}\n+\n # This is not among top-level (test_expect_success | test_expect_failure)\n # but is a prefix that can be used in the test script, like:\n #\n-- \n1.7.4.1\n"},{"id":"161715","messageId":"4D602456.3020200@gmail.com","threadId":"26516","inReplyTo":"20110218231748.GA17836@elie","subject":"Re: [PATCH] Documentation: cherry-pick does not set ORIG_HEAD","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-02-19T20:13:10Z","receivedAt":"2011-02-19T20:13:10Z","isPatch":true,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"W dniu 19.02.2011 00:17, Jonathan Nieder pisze:\n>>> \"git reset --merge\" will remove local changes marked with \"git add\",\n>>> under the assumption that they were part of the conflict resolution\n>>> and thus should be cleared away.\n>>\n>> Didn't know that (one probably shouldn't merge with uncommitted/local\n>> changes anyway). git-reset.txt mentions it, but there's no explicit\n>> warning.\n> \n> Care to write a patch?\n\nI tried but gave up :( \n\n\n>> Is it possible to recognize that you have something more than what\n>> was cause by the merge/cherry-pick?\n> \n> I suppose it depends what you mean.  I see at least two distinct\n> problems to solve:\n> \n>  A. \"undo\" facility to recover from an ugly cherry-pick\n\nThat's what I meant. There's a 'git merge --abort', the same should be\navailable for cherry-pick.\n\nIf I understand correctly, this requires changes to cherry-pick to \nset ORIG_HEAD?\n\n\n> This one is what reset --merge is for.  The idea is that after\n> spending a little while trying to make something good out of a\n> mess, you say, \"oh, bother, let me get back to where I started\".\n\nMaybe 'git cherry-pick --abort' could do 'reset --merge' internally.\nYou would not have to remember \"ok, for merge I can do --abort, \nbut for cherry pick I must do reset --merge\".\n\n\n> So in this case it really does make sense to back out any changes\n> you marked with \"git add\" after the cherry-pick, since they were\n> part of the messy resolution process.  If there had been any\n> changes registered before the cherry-pick, the cherry-pick would\n> have just failed without making a mess.\n\nIndeed, cherry-pick won't start if there are any stashed changes. \nI wasn't aware about this.\n\nWhich is a bit \tstrange: why cherry-pick behaves differently than merge?\n(merge allows staged changes when merging, cherry-pick doesn't).\nShouldn't they work the same, i.e. allow merge or cherry-pick if the\nchanges are not conflicting?\n\n\nAnyway, cherry-pick refuses to work if you have staged changes, but still\ndoesn't mind local unstaged changes. Which makes possible following case:\n\n   do some local hacking, do not stage yet\n   cherry-pick commit with merge conflicts\n   try to resolve them, adding local changes in meantime\n   give up and try to abort with 'git reset --merge'\n\nIn result your local changes will be lost. I don't know how real such\nsituation is, but maybe git could/should prevent it?\n\nFor example by saying \"you're trying to abort merge, but it will also\nrevert your local changes from before the merge\".\n \n\n> A patch in flight makes \"git cherry-pick\" print advice for this case\n> when it encounters conflicts (thanks!).\n\nNice :)\n\n \n\n-- \nPiotr Krukowiecki\n"}]}