linux-kernel - Re: Announce: Linux-next (Or Andrew's dream :-))

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.00.0802121936450.2920@woody.linux-foundation.org>
Date:	Tue, 12 Feb 2008 19:48:31 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	David Miller <davem@...emloft.net>, jeff@...zik.org,
	arjan@...radead.org, greg@...ah.com, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/