rebasing a merge

Say you have:

-o--o--o--m master
         /
--o--o--o   side

You're ready to push the merge, but in the mean time:

         o--o--o origin/master
        /
-o--o--o--m master
         /
--o--o--o   side

For various reasons, when this happens I want to rebase my merge (m). It is almost always a merge that involves a fair amount of conflict resolution. Here's how I've been doing it, but I'll bet there's a less convoluted way:

git merge origin/master # resolve as needed git branch -f temp # save the tree git reset --hard ORIG_HEAD # restore back to the merge git rebase -i -p --onto origin/master HEAD~1 # rebase the merge git checkout temp -- . # resolve the conflict here git rebase --continue # commit the resolution git diff temp # no differences git branch -D temp

Thoughts?

j.

On Thu, Jun 17, 2010 at 11:51 AM, Jay Soffian <jaysoffian@gmail.com> wrote:

This is a bit more efficient:

mc=$(git rev-parse HEAD) p1=$(git rev-parse origin) p2=$(git rev-parse HEAD^2) git merge origin || exit 0 tree=$(git log -1 HEAD --pretty=%T) git reset --hard $(git cat-file commit $mc | sed '1,/^$/d' | git commit-tree $tree -p $p1 -p $p2)

Jay Soffian:

Do you have git-rerere enabled? I have found that to be a major timesaver for cases like these.

On Fri, Jun 18, 2010 at 5:10 AM, Peter Krefting <peter@softwolves.pp.se> wrote:

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.

Jay Soffian:

Yes, of course, sorry for not recognizing your name :-)

So, you want to just discard the change in the new commit on the branch you merged?

You could probably get off by "git cat-file" the commit object, changing the parent reference to point to the newly introduced commit while leaving the rest intact, and then "git hash-object" the new commit object, and then forward the branch head to that one.

On Thu, Jun 24, 2010 at 5:16 AM, Peter Krefting <peter@softwolves.pp.se> wrote:

Did you miss my followup message?

http://article.gmane.org/gmane.comp.version-control.git/149335

j.