From: Shawn O. Pearce <spearce@spearce.org>
Date: Mon, 20 Aug 2007 05:58:09 GMT
Subject: Re: How to do a reverse rebase?
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.