On Fri, Jun 18, 2010 at 5:10 AM, Peter Krefting <peter@xxxxxxxxxxxxxxxx> wrote: > Jay Soffian: > >> Here's how I've been doing it, but I'll bet there's a less convoluted way: > > Do you have git-rerere enabled? I have found that to be a major timesaver > for cases like these. I'm familiar with rerere. The problem is that my original merge often takes me several attempts to get correct, where each attempt I'm amending the merge. So once the merge is finally correct, I need to retrain rerere (see my earlier post to the list about this). Now at that point, I could use "git rebase -i -p --onto ..." to redo the merge and let rerere take care of the conflict resolution. Which is what I was doing. But it occurred to me that the final tree that I want is the same as if I just do a second merge, save that off, then redo my original merge and commit it with the second merge's tree. This is also a lot faster (this repo is 1GB well packed composed of 40k files) and I think less error prone. j. -- 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