A script for rebasing a merge

remerge

#!/bin/sh -x
# remerge <onto> [<merge_commit>]
# e.g.: remerge origin/trunk
# merge_commit defaults to HEAD

onto=$1
mc=${2:-HEAD}

mc_sha=$(git rev-parse $mc)    # original merge commit
p1_sha=$(git rev-parse $onto)  # what we want its new first parent to be
p2_sha=$(git rev-parse $mc^2)  # keep the original second parent
# write out a script to finish the merge in case the merge step has conflicts
cat >finish_merge.sh<<__EOF__
tree=\$(git log -1 HEAD --pretty=%T)
git reset --hard \$(git cat-file commit $mc_sha | sed '1,/^$/d' | git commit-tree \$tree -p $p1_sha -p $p2_sha)
__EOF__
git checkout $mc_sha           # checkout the merge commit
git merge $p1_sha || { echo "Resolve and commit the merge; then run finish_merge.sh"; exit 1; }
# recreate the original merge using this new tree and new first parent
. ./finish_merge.sh
rm -f finish_merge.sh

this script seems terribly over-complicated to me. the core of a sufficient process is this:

git merge --no-commit -s ours candidate^2
git cherry-pick -m 1 candidate

this may cause new conflicts that need to be resolved, and the resolution committed the usual way.

Wow. This is an eight-year old gist. I'm almost certain the -m option to cherry-pick didn't exist at the time. (I was a git contributor around that time frame and I was pretty familiar with it.)

In any case, I wrote this while I was working at a startup that was shipping a fork of Chromium, and when I was responsible for merging Chromium development daily into our fork. It did the job just fine. Thanks for the feedback though.

Looks like -m was added in late 2007. Not sure why I wrote the script the way I did.