What's the best method between merging and rebasing ?

What's the best method between merging and rebasing ?

[Xavier Maillard]

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.

How would you do that ?

I think I can't merge directly old master onto new master since
there are several commits I want to drop but what about rebasing
?

I guess I should cherry-pick interesting commits and rebase but I
am not sure.

Help would be greatly appreciated here :)
-- 
Xavier

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

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

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.

  then delete the master branch, and branch it again from the "orig
master", then cherry pick from old-master what you want to keep.

  Of course those approachs only "work" if nobody clones your
repository, as you will rewrite history with that.

  But Maybe I missed what you want to achieve :)

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Xavier Maillard]

   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 :)

Thank you
-- 
Xavier

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

[Johannes Sixt]

Xavier Maillard wrote:
> -> 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 :)

Just to get the wording straight: You mean "reset master to new HEAD",
not "rebase". "reset" means to point the branch identifier ("master") to
some commit - with or without modifying the working directory
accordingly. OTOH, "rebase" means to re-apply a string of commits on top
of some other commit.

-- Hannes

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

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On Mon, Mar 12, 2007 at 06:11:27PM +0100, Johannes Sixt wrote:
> Xavier Maillard wrote:
> > -> 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 :)
> 
> Just to get the wording straight: You mean "reset master to new HEAD",
> not "rebase". "reset" means to point the branch identifier ("master") to
> some commit - with or without modifying the working directory
> accordingly. OTOH, "rebase" means to re-apply a string of commits on top
> of some other commit.
  
  err that was indeed a lapsus from me. Sorry for the mistake, that was
indeed what I intended to say.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 2682 bytes --]

On Mon, Mar 12, 2007 at 05:34:55PM +0100, Xavier Maillard wrote:
>    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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Xavier Maillard]

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

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

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 2817 bytes --]

On Mon, Mar 12, 2007 at 08:14:52PM +0100, Xavier Maillard wrote:
> 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.

  git branch -m does that, it renames a branch. so git branch -m master
old-master does that. it's what I said in my previous mail.

> 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.

  the image I use to about "reset" is that reset is placing a "cursor"
onto a specific commit. Meaning that if you reset master onto some
"commit" it makes master HEAD be that specicific commit.

  the same applies if you do : `git reset HEAD~10' in your working
checkout, it places your current HEAD onto HEAD~10. And so on.

> 
> 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).
  before the master you have to:

  $ git branch -m master old-master
and instead of the reset I'd do
  $ git branch master HEAD
as you don't have any master around after the previous move.



> P.S: I have problems reading your posts, my mail buffer is full
> of =20 here and there

  that's probable because your MUA does not uderstands quoted printeable
properly ? It is advertised correctly in the Content-Transfer-Encodings
of my mail mimepart so it's not a problem on my end IMHO.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]