Re: How to do a reverse rebase?

From: Shawn O. Pearce <spearce@spearce.org>
Date: Aug 20, 2007, 05:58 UTC
Message-ID: <20070820055809.GZ27913@spearce.org>
In-Reply-To: <20070820053237.9349.qmail@science.horizon.com>

linux@horizon.com wrote:

> I don't want to rebase HEAD on *that*, but rather rebase *that*
> on top of the current HEAD.

...

> Currently, when I remember, I'll use git-cherry-pick and manually
> rename branches.
> 
> Is there an easier way?

I don't think so. To do the merge of those files we need a working directory to operate in; that working directory is the one you have. It sounds like what you want is this:

	old=`git symbolic-ref HEAD` &&
	git checkout HEAD^0 &&
	git cherry-pick debug_hack &&
	git branch -f debug_hack HEAD &&
	git checkout $old

What's really needed is to avoid switching to the branch, as you mentioned. Instead switch to the --onto (implied or given by user). That way you can avoid updating a lot of files in the working directory for no (compelling) reason. Looking at the part of git-rebase.sh that is affected by this (l.284-322) this is probably not that difficult to improve. Just a little bit of work to keep track of everything.

Of course `git-rebase -i` is a completely different implementation, so now you are also talking about l.409-480 of that. Ick.

> Or should I just learn StGit?

Probably. It handles patch stacks easier than core Git. Or so I'm told. I find `git rebase -i` good enough for my needs, but it going first to the debug_hack branch, then to the onto does sort of suck.

-- 
Shawn.