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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
