On Jun 15, 2012, at 10:19 PM, Junio C Hamano wrote: > David Kilzer <ddkilzer@xxxxxxxxxx> writes: > >> 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? 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. > In other words, do you need to do anything special to make the > command honour rerere.autoupdate? Yes, there are two changes required to make it behave this way, both in git-rebase--interactive.sh in the same locality: 1. Pass --rerere-autoupdate to git-merge if rerere.autoupdate is true. 2. Run git-update-index (before dying) to determine if all conflicts were successfully resolved and commit the result if so, else die as before. There 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. This 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. I 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? > 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." Yes, that sounds reasonable. What would be the best way to store this rebase-only switch? Does 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.) Or would it be best just to touch an empty file in .git/rebase-*/ for this purpose? 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