David Kilzer <ddkilzer@xxxxxxxxxx> writes: >> The configuration rerere.enabled *never* meant that the user blindly >> trusts the result of replaying a previous resolution. If you were >> checking rerere.autoupdate configuration variable, the patch may >> have made some sense, but basing the decision on rerere.enabled >> (which by the way is not necessary to trigger the rerere machinery >> these days, as long as $GIT_DIR/rr-cache/ directory exists) sounds >> very wrong. > > Thanks! I'll repost the patch based on rerere.autoupdate for further discussion. 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? In other words, do you need to do anything special to make the command honour rerere.autoupdate? Assuming that your patch does not need to do anything special based on the rerere.autoupdate configuration (because the underlying "merge" may automatically take care of it), I think what you need may be a mechanism to give --[no-]rerere-autoupdate option to "git rebase -m/-i/-p" and pass that option to the invocation of underlying "git merge", so that the user who does not usually want to blindly trust the replayed resolution (hence rerere.autoupdate configured to false) can choose to tell the "git rebase -m/-i/-p" command that "for this single invocation it is OK to trust the replayed resolution". Or the other way around, i.e. "Even though I have rerere.autoupdate configured to true, for this single invocation of 'rebase', I am giving the '--no-rerere-autoupdate' option to tell you that you should _not_ blindly replay the resolution." Hrm? -- 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