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

[Pierre Habouzit <madcoder@debian.org>]

[-- 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 --]