Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled
On Jun 15, 2012, at 10:19 PM, Junio C Hamano wrote:
Show 8 quoted lines
> David Kilzer <ddkilzer@kilzer.net> 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?
Show 14 quoted lines
> 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
David Kilzer <ddkilzer@kilzer.net>