On Tue, 12 Feb 2008, Linus Torvalds wrote: > > git rebase --onto $new $old ..and in case it wasn't clear - this is just a general way of saying "move the commits on this branch since $old to be based on top of $new" instead. You can pick out those old/new commit ID's using gitk or whatever if you wish. Neither the $new or the $old needs to even be an existing branch - just pick them with gitk. So if you literally want to just move the top 5 commits (assuming those top five cmmits are just a nice linear thing you did) from the current branch to be on top on another branch instead, you can literally do this: # save this state, maybe we want to keep it around. Call it "old" git branch old-branch # rebase the top five commits onto $target git rebase --onto $target HEAD~5 ta-daa - all done. The branch you are on will now have been rewritten to be the top five commits moved to be on top of the $target you chose, and if you want to get back the old state, it's nicely squirrelled away in "old-branch". (That obviously assumes no merge conflicts - you'll have to resolve those yourself ;) Of course, if you didn't even want to save the old branch, just skip the first step. If you have reflogs enabled (and git does that by default in any half-way recent version), you can always find it again, even without having to do "git fsck --lost-found", at least as long as you don't delete that branch, and it hasn't gotten pruned away (kept around for the next 90 days by default, iirc) Linus - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
