rebasing a merge

rebasing a merge

[Jay Soffian]

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.

Re: rebasing a merge

[Jay Soffian]

On Thu, Jun 17, 2010 at 11:51 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> 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

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)

Re: rebasing a merge

[Peter Krefting]

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.

-- 
\\// Peter - http://www.softwolves.pp.se/

Re: rebasing a merge

[Jay Soffian]

On Fri, Jun 18, 2010 at 5:10 AM, Peter Krefting <peter@softwolves.pp.se> 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.

Re: rebasing a merge

[Peter Krefting]

Jay Soffian:

> I'm familiar with rerere.

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

> 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,

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.

-- 
\\// Peter - http://www.softwolves.pp.se/

Re: rebasing a merge

[Jay Soffian]

On Thu, Jun 24, 2010 at 5:16 AM, Peter Krefting <peter@softwolves.pp.se> wrote:
> 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.

Did you miss my followup message?

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

j.