From: Xavier Maillard <zedek@gnu.org>
Date: Mon, 12 Mar 2007 19:14:52 GMT
Subject: Re: What's the best method between merging and rebasing ?
Message-ID: <200703121914.l2CJEqW0031669@localhost.localdomain>
In-Reply-To: <20070312173727.GC30489@mad.intersec.eu>

Hi,

   From: Pierre Habouzit <madcoder@debian.org>

   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