+ Johannes Schindelin [sorry, should have added you at the beginning of the thread] On Jun 16, 2012, at 10:49 PM, Junio C Hamano wrote: > David Kilzer <ddkilzer@xxxxxxxxxx> writes: > >> On Jun 15, 2012, at 10:19 PM, Junio C Hamano wrote: >> >>> I do not use the configuration variable myself, and I didn't check >>> the code, but if you had rerere.autoupdate set, doesn't "git merge" >>> in the codepath you are touching (or anywhere for that matter) >>> already blindly take the replayed resolution and commit the result? >> >> No, 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. > > After looking at what is done in t/t4200-rerere.sh, I think "git > merge" (or anything that use --rerere-autoupdate, that is) is meant > to exit with an error code after allowing rerere to add the result > of replayed resolution to the index, so that the user can deal with > any remaining paths that may be still in conflict. > > Are you sure that the autoresolved paths are not "git add"ed when > you have rerere.autoupdate set by "git merge" in "git rebase -i/-p"? You are correct, autoresolved paths are "git add"ed when rerere.autoupdate is true. Argh...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. > Or are you only talking about the error exit from "git merge" that > would cause "git rebase -i" to stop and give control back to the end > user? > > I suspect that the latter behaviour to stop "rebase" in the middle > is in line with the spirit of --rerere-autoupdate, and it is not > likely that we would want to change it. If 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. Dave -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html