linux@xxxxxxxxxxx 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
