Re: What's the best method between merging and rebasing ?

From: Pierre Habouzit <madcoder@debian.org>
Date: Mar 12, 2007, 17:37 UTC
Message-ID: <20070312173727.GC30489@mad.intersec.eu>
In-Reply-To: <200703121634.l2CGYtGx027263@localhost.localdomain>

On Mon, Mar 12, 2007 at 05:34:55PM +0100, Xavier Maillard wrote:

Show 32 quoted lines

>    From: Pierre Habouzit <madcoder@debian.org>
> 
>    On Mon, Mar 12, 2007 at 12:39:38PM +0100, Xavier Maillard wrote:
>    > Hi,
> 
>    > Say I have a project in this state:
> 
>    > orig master -> A -> B -> C -> HEAD
> 
>    > I want to make A diverging from the original branch so I would be
>    > at this state :
> 
>    > orig master -> A -> B -> C -> HEAD
>    >      	    \
>    > 	             -> D -> E -> F ->
> 
>    > I want master to be at  HEAD of the new branch and I want to pick
>    > commits here and there from the original master branch.
> 
>      I'm not sure I get this right, but if I understand you correctly, I'd
>    say that you could branch your master into a old-master branch.
> 
> What I am tryin to explain is that I want to get rid of the old
> master branch and pick commits from it here and there (that's
> what is called cherry-pick I guess).
> 
> So in the end I will end with:
> 
> -> D -> E -> F -> several commits from old master -> HEAD (of new master)
> 
> 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

  we now have:

orig master -> A -> B -> C  (master)
      	    \
             -> D -> E -> F -> A' -> C' (topic)

  $ git branch -D master       # we don't want to keep master anymore
  $ git branch -m topic master # rename topic branch into master

  The last step will loose B completely, so if you want to keep it, you
want to keep an old master HEAD around so that references to that branch
remain somwhere. You could git branch -m master old-master at step 3
rather than deleting it in that case.

  But beware that if you do that, as you basically rewrote master's
history, if anyone fetchs from your master, you will f**k up his branch,
because you rewrote history. In that case I think you have to commit a
reverse patch for B (and all the other patches you want to remove) and
then merge topic into master. Your call :)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org