Hi,
From: Pierre Habouzit <madcoder@xxxxxxxxxx>
On Mon, Mar 12, 2007 at 05:34:55PM +0100, Xavier Maillard wrote:
> So it seems to be cherry-picks + rebase master on new HEAD but I
> am not sure at how things are doing :)
okay then I got this right, you don't want to rebase master on new
HEAD because you would keep the commits you don't want (I guess). What
you start from:
orig master -> A -> B -> C (master)
\
-> D -> E -> F topic
let's say you want to keep A and C from master. here is what I'd do:
$ git checkout topic # topic will be the new master
$ git cherry-pick A C # we want to keep A and C
Got it for this one :)
we now have:
orig master -> A -> B -> C (master)
\
-> D -> E -> F -> A' -> C' (topic)
$ git branch -D master
For historical reasons, I have to keep my master around so I
won't delete it completely. Maybe there is a way to tell that a
branch is considered "dead" thus indicating there won't be any
new developement onto it. I will check this.
As I have been told privately, what I want in reality is a reset
of master onto my new HEAD.
I think I have misunderstood reset behaviour.
So this is how I end up now (from my new master branch):
$ git cherry-pick <commits>
$ git rebase master~NUM
$ git reset master HEAD
There I would need something to tell old master is dead but it is
optionnal (a single tag will do that).
Does that make sense for you ?
Regards,
P.S: I have problems reading your posts, my mail buffer is full
of =20 here and there
--
Xavier
-
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