{"thread":{"id":"30816","subject":"[PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","startedAt":"2012-06-15T14:17:35Z","lastAt":"2012-06-18T19:06:36Z","messageCount":12,"participants":["David D. Kilzer","Junio C Hamano","David Kilzer","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"193701","messageId":"1339769855-94161-1-git-send-email-ddkilzer@kilzer.net","threadId":"30816","inReplyTo":null,"subject":"[PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"David D. Kilzer","fromEmail":"ddkilzer@kilzer.net","sentAt":"2012-06-15T14:17:35Z","receivedAt":"2012-06-15T14:17:35Z","isPatch":true,"sender":{"key":"ddkilzer@kilzer.net","avatar":"https://avatars.githubusercontent.com/u/263571?v=4"},"body":"From: \"David D. Kilzer\" \n\nWhen performing an interactive rebase that preserves merges with\nrerere enabled, the --rerere-autoupdate switch should be passed\nto git-merge.\n\nSigned-off-by: David D. Kilzer \n---\n git-rebase--interactive.sh | 7 ++-\n t/t3420-rebase-preserve-merges-with-rerere.sh | 75 +++++++++++++++++++++++++\n 2 files changed, 80 insertions(+), 2 deletions(-)\n create mode 100755 t/t3420-rebase-preserve-merges-with-rerere.sh\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 2e13258..958bbf8 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -297,9 +297,12 @@ pick_one_preserving_merges () {\n \t\t\tmsg_content=\"$(commit_message $sha1)\"\n \t\t\t# No point in merging the first parent, that's HEAD\n \t\t\tnew_parents=${new_parents# $first_parent}\n+\t\t\t# If rerere is enabled, pass the --rerere-autoupdate flag\n+\t\t\ttest \"$(git config --bool rerere.enabled)\" = \"true\" &&\n+\t\t\t\trerere_autoupdate=--rerere-autoupdate || rerere_autoupdate=\n \t\t\tif ! do_with_author output \\\n-\t\t\t\tgit merge --no-ff ${strategy:+-s $strategy} -m \\\n-\t\t\t\t\t\"$msg_content\" $new_parents\n+\t\t\t\tgit merge --no-ff ${strategy:+-s $strategy} $rerere_autoupdate \\\n+\t\t\t\t\t-m \"$msg_content\" $new_parents\n \t\t\tthen\n \t\t\t\tprintf \"%s\\n\" \"$msg_content\" > \"$GIT_DIR\"/MERGE_MSG\n \t\t\t\tdie_with_patch $sha1 \"Error redoing merge $sha1\"\ndiff --git a/t/t3420-rebase-preserve-merges-with-rerere.sh b/t/t3420-rebase-preserve-merges-with-rerere.sh\nnew file mode 100755\nindex 0000000..679937d\n--- /dev/null\n+++ b/t/t3420-rebase-preserve-merges-with-rerere.sh\n@@ -0,0 +1,75 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2007 Johannes E. Schindelin\n+# Copyright (c) 2012 David D. Kilzer\n+#\n+\n+test_description='git rebase -i -p should use rerere to resolve conflicts if enabled'\n+. ./test-lib.sh\n+\n+. \"$TEST_DIRECTORY\"/lib-rebase.sh\n+\n+set_fake_editor\n+\n+# Setup\n+#\n+# A--AA--B <-- master\n+# \\\n+# \\\n+# \\\n+# C <-- topic1\n+\n+test_expect_success 'setup' '\n+\ttest_commit A file1 &&\n+\ttest_commit AA file2 &&\n+\ttest_commit B file1 &&\n+\tgit checkout -b topic1 HEAD^ &&\n+\ttest_commit C file1 &&\n+\tgit checkout master\n+'\n+\n+# Use rerere to resolve conflicts\n+#\n+# Before interactive rebase:\n+#\n+# A--AA--B <-- master\n+# \\ \\\n+# \\ M <-- merge1-baseline, merge1\n+# \\ /\n+# C <-- topic1\n+#\n+# After interactive rebase:\n+#\n+# A--AA--B <-- master\n+# |\\ \\\n+# | \\ M <-- merge1-baseline\n+# | \\ /\n+# | C <-- topic1\n+# \\ \\\n+# \\ M' <-- merge1\n+# \\ /\n+# B'\n+\n+test_expect_success 'rebase -i -p uses rerere to resolve conflicts' '\n+\tgit config rerere.enabled true &&\n+\tgit rerere clear &&\n+\n+\tgit checkout -b merge1 master &&\n+\ttest_must_fail git merge topic1 &&\n+\ttest \"`git rerere status`\" = \"file1\" &&\n+\tprintf \"B\\nC\\n\" > file1 &&\n+\tgit add file1 &&\n+\tgit commit -m \"M: Merge with conflict resolved.\" &&\n+\tgit branch merge1-baseline &&\n+\n+\tFAKE_LINES=\"edit 1 2 3\" git rebase -i -p HEAD~2 &&\n+\techo BB >> file2 &&\n+\tgit add file2 &&\n+\tgit commit -m \"B'\\'': Edit file2 to prevent fast-forward.\" --amend &&\n+\ttest_must_fail git rebase --continue &&\n+\tgit commit -m \"M'\\'': Merge with conflict resolved by rerere.\" &&\n+\tgit rebase --continue &&\n+\tgit diff --exit-code merge1-baseline..merge1 file1\n+'\n+\n+test_done\n-- \n1.7.9.6 (Apple Git-31)\n"},{"id":"193703","messageId":"7vwr38bmj5.fsf@alter.siamese.dyndns.org","threadId":"30816","inReplyTo":"1339769855-94161-1-git-send-email-ddkilzer@kilzer.net","subject":"Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-15T15:52:14Z","receivedAt":"2012-06-15T15:52:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"David D. Kilzer\" writes:\n\n> From: \"David D. Kilzer\" \n>\n> When performing an interactive rebase that preserves merges with\n> rerere enabled, the --rerere-autoupdate switch should be passed\n> to git-merge.\n\nI do not understand the above reasoning.\n\n\"rerere\" is enabled in \"merge\" used in this codepath already, so\nafter it runs, you will see the result of automatically replaying\na previous resolution without your patch.\n\nThe configuration rerere.enabled *never* meant that the user blindly\ntrusts the result of replaying a previous resolution. If you were\nchecking rerere.autoupdate configuration variable, the patch may\nhave made some sense, but basing the decision on rerere.enabled\n(which by the way is not necessary to trigger the rerere machinery\nthese days, as long as $GIT_DIR/rr-cache/ directory exists) sounds\nvery wrong.\n"},{"id":"193749","messageId":"B4036488-1ECA-41C9-BD97-B2ABD116D54C@kilzer.net","threadId":"30816","inReplyTo":"7vwr38bmj5.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"David Kilzer","fromEmail":"ddkilzer@kilzer.net","sentAt":"2012-06-16T04:08:12Z","receivedAt":"2012-06-16T04:08:12Z","isPatch":true,"sender":{"key":"ddkilzer@kilzer.net","avatar":"https://avatars.githubusercontent.com/u/263571?v=4"},"body":"On Jun 15, 2012, at 8:52 AM, Junio C Hamano wrote:\n\n> \"David D. Kilzer\" writes:\n> \n>> From: \"David D. Kilzer\" \n>> \n>> When performing an interactive rebase that preserves merges with\n>> rerere enabled, the --rerere-autoupdate switch should be passed\n>> to git-merge.\n> \n> I do not understand the above reasoning.\n> \n> \"rerere\" is enabled in \"merge\" used in this codepath already, so\n> after it runs, you will see the result of automatically replaying\n> a previous resolution without your patch.\n> \n> The configuration rerere.enabled *never* meant that the user blindly\n> trusts the result of replaying a previous resolution. If you were\n> checking rerere.autoupdate configuration variable, the patch may\n> have made some sense, but basing the decision on rerere.enabled\n> (which by the way is not necessary to trigger the rerere machinery\n> these days, as long as $GIT_DIR/rr-cache/ directory exists) sounds\n> very wrong.\n\nThanks! I'll repost the patch based on rerere.autoupdate for further discussion.\n\nDave\n"},{"id":"193750","messageId":"7vd34z96lv.fsf@alter.siamese.dyndns.org","threadId":"30816","inReplyTo":"B4036488-1ECA-41C9-BD97-B2ABD116D54C@kilzer.net","subject":"Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-16T05:19:08Z","receivedAt":"2012-06-16T05:19:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kilzer writes:\n\n>> The configuration rerere.enabled *never* meant that the user blindly\n>> trusts the result of replaying a previous resolution. If you were\n>> checking rerere.autoupdate configuration variable, the patch may\n>> have made some sense, but basing the decision on rerere.enabled\n>> (which by the way is not necessary to trigger the rerere machinery\n>> these days, as long as $GIT_DIR/rr-cache/ directory exists) sounds\n>> very wrong.\n>\n> Thanks! I'll repost the patch based on rerere.autoupdate for further discussion.\n\nI do not use the configuration variable myself, and I didn't check\nthe code, but if you had rerere.autoupdate set, doesn't \"git merge\"\nin the codepath you are touching (or anywhere for that matter)\nalready blindly take the replayed resolution and commit the result?\n\nIn other words, do you need to do anything special to make the\ncommand honour rerere.autoupdate?\n\nAssuming that your patch does not need to do anything special based\non the rerere.autoupdate configuration (because the underlying\n\"merge\" may automatically take care of it), I think what you need\nmay be a mechanism to give --[no-]rerere-autoupdate option to \"git\nrebase -m/-i/-p\" and pass that option to the invocation of\nunderlying \"git merge\", so that the user who does not usually want\nto blindly trust the replayed resolution (hence rerere.autoupdate\nconfigured to false) can choose to tell the \"git rebase -m/-i/-p\"\ncommand that \"for this single invocation it is OK to trust the\nreplayed resolution\". Or the other way around, i.e. \"Even though I\nhave rerere.autoupdate configured to true, for this single\ninvocation of 'rebase', I am giving the '--no-rerere-autoupdate'\noption to tell you that you should _not_ blindly replay the\nresolution.\"\n\nHrm?\n"},{"id":"193755","messageId":"76A6615B-5758-4D67-A556-2EE131FF7B20@kilzer.net","threadId":"30816","inReplyTo":"7vd34z96lv.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"David Kilzer","fromEmail":"ddkilzer@kilzer.net","sentAt":"2012-06-17T03:58:55Z","receivedAt":"2012-06-17T03:58:55Z","isPatch":true,"sender":{"key":"ddkilzer@kilzer.net","avatar":"https://avatars.githubusercontent.com/u/263571?v=4"},"body":"On Jun 15, 2012, at 10:19 PM, Junio C Hamano wrote:\n\n> David Kilzer writes:\n> \n>> Thanks! I'll repost the patch based on rerere.autoupdate for further discussion.\n> \n> I do not use the configuration variable myself, and I didn't check\n> the code, but if you had rerere.autoupdate set, doesn't \"git merge\"\n> in the codepath you are touching (or anywhere for that matter)\n> already blindly take the replayed resolution and commit the result?\n\nNo, it does not. That is what I originally expected to happen when I used \"git rebase -i -p\" through a merge with conflicts, but it currently does not behave this way.\n\n> In other words, do you need to do anything special to make the\n> command honour rerere.autoupdate?\n\nYes, there are two changes required to make it behave this way, both in git-rebase--interactive.sh in the same locality:\n\n1. Pass --rerere-autoupdate to git-merge if rerere.autoupdate is true.\n2. Run git-update-index (before dying) to determine if all conflicts were successfully resolved and commit the result if so, else die as before.\n\nThere is one big caveat to #2, though. If the original (pre-rebase) merge commit contained changes to a non-conflicted file, those changes will be lost if all of the conflicted files are auto-updated using rerere.\n\nThis is actually a real concern in a particular git repository that I maintain where I'm merging individual commits from two different git-svn repositories into a third pure-git tree. (One svn tree is essentially a branch of the other.) I merge individual commits from both git-svn trees to provide the highest fidelity for (potential future) git-bisect operations. When I hit a build failure after ~100 commits, I determine how best to fix it, then run \"git rebase -i -p\" to inject the fix in the proper merge commit. Occasionally I catch a build failure when resolving a conflict, which may also cause me to change a non-conflicted file.\n\nI now have a patch series for #1 and #2 (including a failing test that provides an example of a change to a non-conflicted file getting lost during \"rebase -i -p\"). Would it be helpful to post this patch series?\n\n> Assuming that your patch does not need to do anything special based\n> on the rerere.autoupdate configuration (because the underlying\n> \"merge\" may automatically take care of it), I think what you need\n> may be a mechanism to give --[no-]rerere-autoupdate option to \"git\n> rebase -m/-i/-p\" and pass that option to the invocation of\n> underlying \"git merge\", so that the user who does not usually want\n> to blindly trust the replayed resolution (hence rerere.autoupdate\n> configured to false) can choose to tell the \"git rebase -m/-i/-p\"\n> command that \"for this single invocation it is OK to trust the\n> replayed resolution\". Or the other way around, i.e. \"Even though I\n> have rerere.autoupdate configured to true, for this single\n> invocation of 'rebase', I am giving the '--no-rerere-autoupdate'\n> option to tell you that you should _not_ blindly replay the\n> resolution.\"\n\n\nYes, that sounds reasonable. What would be the best way to store this rebase-only switch?\n\nDoes git-config have a per-rebase-operation mode where config options can be read/written for the duration of a specific rebase operation such that these config settings override all the other config files? That has the potential to provide a better separation of concerns rather than creating yet another one-off file in .git/rebase-*/. (May want to add an extra flag to git-config like --check-rebase or --rebase to make it check for .git/rebase-*/config before .git/config since that probably shouldn't be the default behavior when the user invokes git-config.)\n\nOr would it be best just to touch an empty file in .git/rebase-*/ for this purpose?\n\nDave\n"},{"id":"193756","messageId":"7vmx427aj0.fsf@alter.siamese.dyndns.org","threadId":"30816","inReplyTo":"76A6615B-5758-4D67-A556-2EE131FF7B20@kilzer.net","subject":"Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-17T05:49:39Z","receivedAt":"2012-06-17T05:49:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kilzer writes:\n\n> On Jun 15, 2012, at 10:19 PM, Junio C Hamano wrote:\n>\n>> I do not use the configuration variable myself, and I didn't check\n>> the code, but if you had rerere.autoupdate set, doesn't \"git merge\"\n>> in the codepath you are touching (or anywhere for that matter)\n>> already blindly take the replayed resolution and commit the result?\n>\n> No, it does not. That is what I originally expected to happen\n> when I used \"git rebase -i -p\" through a merge with conflicts, but\n> it currently does not behave this way.\n\nAfter looking at what is done in t/t4200-rerere.sh, I think \"git\nmerge\" (or anything that use --rerere-autoupdate, that is) is meant\nto exit with an error code after allowing rerere to add the result\nof replayed resolution to the index, so that the user can deal with\nany remaining paths that may be still in conflict.\n\nAre you sure that the autoresolved paths are not \"git add\"ed when\nyou have rerere.autoupdate set by \"git merge\" in \"git rebase -i/-p\"?\n\nOr are you only talking about the error exit from \"git merge\" that\nwould cause \"git rebase -i\" to stop and give control back to the end\nuser?\n\nI suspect that the latter behaviour to stop \"rebase\" in the middle\nis in line with the spirit of --rerere-autoupdate, and it is not\nlikely that we would want to change it.\n"},{"id":"193761","messageId":"1917D067-6FB3-4393-B178-BBE36B4B5D4E@kilzer.net","threadId":"30816","inReplyTo":"7vmx427aj0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"David Kilzer","fromEmail":"ddkilzer@kilzer.net","sentAt":"2012-06-17T13:46:03Z","receivedAt":"2012-06-17T13:46:03Z","isPatch":true,"sender":{"key":"ddkilzer@kilzer.net","avatar":"https://avatars.githubusercontent.com/u/263571?v=4"},"body":"+ Johannes Schindelin [sorry, should have added you at the beginning of the thread]\n\nOn Jun 16, 2012, at 10:49 PM, Junio C Hamano wrote:\n\n> David Kilzer writes:\n> \n>> On Jun 15, 2012, at 10:19 PM, Junio C Hamano wrote:\n>> \n>>> I do not use the configuration variable myself, and I didn't check\n>>> the code, but if you had rerere.autoupdate set, doesn't \"git merge\"\n>>> in the codepath you are touching (or anywhere for that matter)\n>>> already blindly take the replayed resolution and commit the result?\n>> \n>> No, it does not. That is what I originally expected to happen\n>> when I used \"git rebase -i -p\" through a merge with conflicts, but\n>> it currently does not behave this way.\n> \n> After looking at what is done in t/t4200-rerere.sh, I think \"git\n> merge\" (or anything that use --rerere-autoupdate, that is) is meant\n> to exit with an error code after allowing rerere to add the result\n> of replayed resolution to the index, so that the user can deal with\n> any remaining paths that may be still in conflict.\n> \n> Are you sure that the autoresolved paths are not \"git add\"ed when\n> you have rerere.autoupdate set by \"git merge\" in \"git rebase -i/-p\"?\n\nYou are correct, autoresolved paths are \"git add\"ed when rerere.autoupdate is true.\n\nArgh...in my original patch, I wasn't setting rerere.autoupdate. After fixing that in the test, it's clear that the patch is no longer needed.\n\n> Or are you only talking about the error exit from \"git merge\" that\n> would cause \"git rebase -i\" to stop and give control back to the end\n> user?\n> \n> I suspect that the latter behaviour to stop \"rebase\" in the middle\n> is in line with the spirit of --rerere-autoupdate, and it is not\n> likely that we would want to change it.\n\nIf it could be guaranteed that all changes in a merge commit would be preserved when running \"git rebase -i -p\" with rerere.autoupdate enabled, I think that would be an argument for not returning control to the user during the rebase operation. However, changes to non-conflicted files in a merge commit are currently lost in this case, so it would be too dangerous to enable this behavior now.\n\nDave\n"},{"id":"193766","messageId":"4FDE2252.5030802@kdbg.org","threadId":"30816","inReplyTo":"1917D067-6FB3-4393-B178-BBE36B4B5D4E@kilzer.net","subject":"Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2012-06-17T18:30:42Z","receivedAt":"2012-06-17T18:30:42Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 17.06.2012 15:46, schrieb David Kilzer:\n> If it could be guaranteed that all changes in a merge commit would be\n> preserved when running \"git rebase -i -p\" with rerere.autoupdate\n> enabled, I think that would be an argument for not returning control\n> to the user during the rebase operation. However, changes to\n> non-conflicted files in a merge commit are currently lost in this\n> case, so it would be too dangerous to enable this behavior now.\n\nYou can test this patch:\n\n git://repo.or.cz/git/mingw/j6t.git preserve-merges-by-cherry-pick\n\nI think it suits you needs unless you run into the one use-case where\nthe patch is a regression (as documented by the new test_expect_failure\nin the test suite).\n\n-- Hannes\n"},{"id":"193770","messageId":"B5E2DD4F-4EEB-4440-A149-DD718B0C2EFD@kilzer.net","threadId":"30816","inReplyTo":"4FDE2252.5030802@kdbg.org","subject":"Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"David Kilzer","fromEmail":"ddkilzer@kilzer.net","sentAt":"2012-06-17T21:30:54Z","receivedAt":"2012-06-17T21:30:54Z","isPatch":true,"sender":{"key":"ddkilzer@kilzer.net","avatar":"https://avatars.githubusercontent.com/u/263571?v=4"},"body":"On Jun 17, 2012, at 11:30 AM, Johannes Sixt wrote:\n\n> Am 17.06.2012 15:46, schrieb David Kilzer:\n>> If it could be guaranteed that all changes in a merge commit would be\n>> preserved when running \"git rebase -i -p\" with rerere.autoupdate\n>> enabled, I think that would be an argument for not returning control\n>> to the user during the rebase operation. However, changes to\n>> non-conflicted files in a merge commit are currently lost in this\n>> case, so it would be too dangerous to enable this behavior now.\n> \n> You can test this patch:\n> \n> git://repo.or.cz/git/mingw/j6t.git preserve-merges-by-cherry-pick\n> \n> I think it suits you needs unless you run into the one use-case where\n> the patch is a regression (as documented by the new test_expect_failure\n> in the test suite).\n\n\nI'd love to try it, but I'm running into an issue pulling the repository:\n\n$ git clone git://repo.or.cz/git/mingw/j6t.git -b preserve-merges-by-cherry-pick j6t.git\nCloning into 'j6t.git'...\nremote: error: Could not read 942cf39b9a36ae27a4377d22093827ef4df25239\nremote: fatal: Failed to traverse parents of commit 051ba02462dd65a0ceb3e527a75f24416378880f\nremote: aborting due to possible repository corruption on the remote side.\nfatal: early EOF\nfatal: index-pack failed\n\n$ git --version\ngit version 1.7.9.6 (Apple Git-31)\n\nDave\n"},{"id":"193771","messageId":"7v62ap7g67.fsf@alter.siamese.dyndns.org","threadId":"30816","inReplyTo":"1917D067-6FB3-4393-B178-BBE36B4B5D4E@kilzer.net","subject":"Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-17T22:00:00Z","receivedAt":"2012-06-17T22:00:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kilzer writes:\n\n> + Johannes Schindelin [sorry, should have added you at the beginning of the thread]\n\nSide note: Dscho, I do not mind hearing from you from time to time,\nbut if the only reason David summoned you is because I mentioned\nt4200 and your name appears at the beginning of that file, and\nunless you are interested in rerere.autoupdate yourself, I am fine\nif you to treat this thread as low priority. Your code in t4200\ndoes not have much to do with rerere.autoupdate which this\ndiscussion thread is about.\n\nI vaguely recall doing the 5-patch series that ends with 121c813\n(rerere.autoupdate, 2008-06-22) after somebody asked if there is a\nway to tell paths that have been resolved by rerere already and\npaths that still need to be sorted out manually (back then I think\nwe had \"rerere status\" but not \"rerere remaining\"), so that \"git\nls-files -u\" can be a more useful command to find out which paths\nneed further work, but I do not seem to be able to find the thread.\nI also think that somebody was a regular in the kernel mailing list,\nbut I do not remember the details. Hopefully somebody with better\nresearch skills (or better memory) than I have can help digging the\ncontext up for us ;-).\n"},{"id":"193772","messageId":"7vy5nl611n.fsf@alter.siamese.dyndns.org","threadId":"30816","inReplyTo":"7vmx427aj0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-17T22:12:04Z","receivedAt":"2012-06-17T22:12:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Or are you only talking about the error exit from \"git merge\" that\n> would cause \"git rebase -i\" to stop and give control back to the end\n> user?\n>\n> I suspect that the latter behaviour to stop \"rebase\" in the middle\n> is in line with the spirit of --rerere-autoupdate, and it is not\n> likely that we would want to change it.\n\nSee this for the background:\n\n http://thread.gmane.org/gmane.comp.version-control.git/85176/focus=85231\n\nThe entire thread (except for articles from a few uninformed\nnoisemakers) is worth a read, as some issues that were discussed\nhave resulted in more recent \"rerere\", and the original inquiry by\nIngo illustrates the motivation behind them quite clearly.\n\nAnd we can see that I was right when I wrote in the above that not\ncommitting is the right thing to do for --rerere-autoupdate /\nrerere.autoupdate even though I did not remember that thread. The\nsecond step described as \"the way forward\" in the quoted article\nhasn't happened yet.\n"},{"id":"193797","messageId":"4FDF7C3C.90300@kdbg.org","threadId":"30816","inReplyTo":"B5E2DD4F-4EEB-4440-A149-DD718B0C2EFD@kilzer.net","subject":"Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2012-06-18T19:06:36Z","receivedAt":"2012-06-18T19:06:36Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 17.06.2012 23:30, schrieb David Kilzer:\n> On Jun 17, 2012, at 11:30 AM, Johannes Sixt wrote:\n> \n>> Am 17.06.2012 15:46, schrieb David Kilzer:\n>>> If it could be guaranteed that all changes in a merge commit would be\n>>> preserved when running \"git rebase -i -p\" with rerere.autoupdate\n>>> enabled, I think that would be an argument for not returning control\n>>> to the user during the rebase operation. However, changes to\n>>> non-conflicted files in a merge commit are currently lost in this\n>>> case, so it would be too dangerous to enable this behavior now.\n>>\n>> You can test this patch:\n>>\n>> git://repo.or.cz/git/mingw/j6t.git preserve-merges-by-cherry-pick\n>>\n>> I think it suits you needs unless you run into the one use-case where\n>> the patch is a regression (as documented by the new test_expect_failure\n>> in the test suite).\n> \n> \n> I'd love to try it, but I'm running into an issue pulling the repository:\n> \n> $ git clone git://repo.or.cz/git/mingw/j6t.git -b preserve-merges-by-cherry-pick j6t.git\n> Cloning into 'j6t.git'...\n> remote: error: Could not read 942cf39b9a36ae27a4377d22093827ef4df25239\n> remote: fatal: Failed to traverse parents of commit 051ba02462dd65a0ceb3e527a75f24416378880f\n> remote: aborting due to possible repository corruption on the remote side.\n> fatal: early EOF\n> fatal: index-pack failed\n\nDon't do that then ;) Enter your favorite git.git clone, then\n\n git pull git://repo.or.cz/git/mingw/j6t.git preserve-merges-by-cherry-pick\n\nshould work like a charm. But I've now removed the branches that\nneeded the missing commit, and your command should work as well.\n\n-- Hannes\n"}]}