{"thread":{"id":"7204","subject":"What's the best method between merging and rebasing ?","startedAt":"2007-03-12T11:39:38Z","lastAt":"2007-03-12T19:43:09Z","messageCount":8,"participants":["Xavier Maillard","Pierre Habouzit","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"36898","messageId":"200703121139.l2CBdcUL022906@localhost.localdomain","threadId":"7204","inReplyTo":null,"subject":"What's the best method between merging and rebasing ?","fromName":"Xavier Maillard","fromEmail":"zedek@gnu.org","sentAt":"2007-03-12T11:39:38Z","receivedAt":"2007-03-12T11:39:38Z","isPatch":false,"sender":{"key":"zedek@gnu.org","avatar":null},"body":"Hi,\n\nSay I have a project in this state:\n\norig master -> A -> B -> C -> HEAD\n\nI want to make A diverging from the original branch so I would be\nat this state :\n\norig master -> A -> B -> C -> HEAD\n \t \\\n\t -> D -> E -> F -> \n\nI want master to be at HEAD of the new branch and I want to pick\ncommits here and there from the original master branch.\n\nHow would you do that ?\n\nI think I can't merge directly old master onto new master since\nthere are several commits I want to drop but what about rebasing\n?\n\nI guess I should cherry-pick interesting commits and rebase but I\nam not sure.\n\nHelp would be greatly appreciated here :)\n-- \nXavier\n"},{"id":"36902","messageId":"20070312120820.GE18952@mad.intersec.eu","threadId":"7204","inReplyTo":"200703121139.l2CBdcUL022906@localhost.localdomain","subject":"Re: What's the best method between merging and rebasing ?","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-03-12T12:08:20Z","receivedAt":"2007-03-12T12:08:20Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Mar 12, 2007 at 12:39:38PM +0100, Xavier Maillard wrote:\n> Hi,\n> \n> Say I have a project in this state:\n> \n> orig master -> A -> B -> C -> HEAD\n> \n> I want to make A diverging from the original branch so I would be\n> at this state :\n> \n> orig master -> A -> B -> C -> HEAD\n> \t \\\n> \t -> D -> E -> F -> \n> \n> I want master to be at HEAD of the new branch and I want to pick\n> commits here and there from the original master branch.\n\n I'm not sure I get this right, but if I understand you correctly, I'd\nsay that you could branch your master into a old-master branch.\n\n then delete the master branch, and branch it again from the \"orig\nmaster\", then cherry pick from old-master what you want to keep.\n\n Of course those approachs only \"work\" if nobody clones your\nrepository, as you will rewrite history with that.\n\n But Maybe I missed what you want to achieve :)\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"36918","messageId":"200703121634.l2CGYtGx027263@localhost.localdomain","threadId":"7204","inReplyTo":"20070312120820.GE18952@mad.intersec.eu","subject":"Re: What's the best method between merging and rebasing ?","fromName":"Xavier Maillard","fromEmail":"zedek@gnu.org","sentAt":"2007-03-12T16:34:55Z","receivedAt":"2007-03-12T16:34:55Z","isPatch":false,"sender":{"key":"zedek@gnu.org","avatar":null},"body":" From: Pierre Habouzit \n\n On Mon, Mar 12, 2007 at 12:39:38PM +0100, Xavier Maillard wrote:\n > Hi,\n\n > Say I have a project in this state:\n\n > orig master -> A -> B -> C -> HEAD\n\n > I want to make A diverging from the original branch so I would be\n > at this state :\n\n > orig master -> A -> B -> C -> HEAD\n > \t \\\n > \t -> D -> E -> F ->\n\n > I want master to be at HEAD of the new branch and I want to pick\n > commits here and there from the original master branch.\n\n I'm not sure I get this right, but if I understand you correctly, I'd\n say that you could branch your master into a old-master branch.\n\nWhat I am tryin to explain is that I want to get rid of the old\nmaster branch and pick commits from it here and there (that's\nwhat is called cherry-pick I guess).\n\nSo in the end I will end with:\n\n-> D -> E -> F -> several commits from old master -> HEAD (of new master)\n\nSo it seems to be cherry-picks + rebase master on new HEAD but I\nam not sure at how things are doing :)\n\nThank you\n-- \nXavier\n"},{"id":"36919","messageId":"45F589BF.28E3A5AD@eudaptics.com","threadId":"7204","inReplyTo":"200703121634.l2CGYtGx027263@localhost.localdomain","subject":"Re: What's the best method between merging and rebasing ?","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-03-12T17:11:27Z","receivedAt":"2007-03-12T17:11:27Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Xavier Maillard wrote:\n> -> D -> E -> F -> several commits from old master -> HEAD (of new master)\n> \n> So it seems to be cherry-picks + rebase master on new HEAD but I\n> am not sure at how things are doing :)\n\nJust to get the wording straight: You mean \"reset master to new HEAD\",\nnot \"rebase\". \"reset\" means to point the branch identifier (\"master\") to\nsome commit - with or without modifying the working directory\naccordingly. OTOH, \"rebase\" means to re-apply a string of commits on top\nof some other commit.\n\n-- Hannes\n"},{"id":"36924","messageId":"20070312173727.GC30489@mad.intersec.eu","threadId":"7204","inReplyTo":"200703121634.l2CGYtGx027263@localhost.localdomain","subject":"Re: What's the best method between merging and rebasing ?","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-03-12T17:37:27Z","receivedAt":"2007-03-12T17:37:27Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Mar 12, 2007 at 05:34:55PM +0100, Xavier Maillard wrote:\n> From: Pierre Habouzit \n> \n> On Mon, Mar 12, 2007 at 12:39:38PM +0100, Xavier Maillard wrote:\n> > Hi,\n> \n> > Say I have a project in this state:\n> \n> > orig master -> A -> B -> C -> HEAD\n> \n> > I want to make A diverging from the original branch so I would be\n> > at this state :\n> \n> > orig master -> A -> B -> C -> HEAD\n> > \t \\\n> > \t -> D -> E -> F ->\n> \n> > I want master to be at HEAD of the new branch and I want to pick\n> > commits here and there from the original master branch.\n> \n> I'm not sure I get this right, but if I understand you correctly, I'd\n> say that you could branch your master into a old-master branch.\n> \n> What I am tryin to explain is that I want to get rid of the old\n> master branch and pick commits from it here and there (that's\n> what is called cherry-pick I guess).\n> \n> So in the end I will end with:\n> \n> -> D -> E -> F -> several commits from old master -> HEAD (of new master)\n> \n> So it seems to be cherry-picks + rebase master on new HEAD but I\n> am not sure at how things are doing :)\n\n okay then I got this right, you don't want to rebase master on new\nHEAD because you would keep the commits you don't want (I guess). What\n\n you start from:\n\norig master -> A -> B -> C (master)\n \t \\\n -> D -> E -> F topic\n\n let's say you want to keep A and C from master. here is what I'd do:\n\n $ git checkout topic # topic will be the new master\n $ git cherry-pick A C # we want to keep A and C\n\n we now have:\n\norig master -> A -> B -> C (master)\n \t \\\n -> D -> E -> F -> A' -> C' (topic)\n\n $ git branch -D master # we don't want to keep master anymore\n $ git branch -m topic master # rename topic branch into master\n\n The last step will loose B completely, so if you want to keep it, you\nwant to keep an old master HEAD around so that references to that branch\nremain somwhere. You could git branch -m master old-master at step 3\nrather than deleting it in that case.\n\n But beware that if you do that, as you basically rewrote master's\nhistory, if anyone fetchs from your master, you will f**k up his branch,\nbecause you rewrote history. In that case I think you have to commit a\nreverse patch for B (and all the other patches you want to remove) and\nthen merge topic into master. Your call :)\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"36941","messageId":"200703121914.l2CJEqW0031669@localhost.localdomain","threadId":"7204","inReplyTo":"20070312173727.GC30489@mad.intersec.eu","subject":"Re: What's the best method between merging and rebasing ?","fromName":"Xavier Maillard","fromEmail":"zedek@gnu.org","sentAt":"2007-03-12T19:14:52Z","receivedAt":"2007-03-12T19:14:52Z","isPatch":false,"sender":{"key":"zedek@gnu.org","avatar":null},"body":"Hi,\n\n From: Pierre Habouzit \n\n On Mon, Mar 12, 2007 at 05:34:55PM +0100, Xavier Maillard wrote:\n\n > So it seems to be cherry-picks + rebase master on new HEAD but I\n > am not sure at how things are doing :)\n\n okay then I got this right, you don't want to rebase master on new\n HEAD because you would keep the commits you don't want (I guess). What\n\n you start from:\n\n orig master -> A -> B -> C (master)\n\t \\\n\t\t-> D -> E -> F topic\n\n let's say you want to keep A and C from master. here is what I'd do:\n\n $ git checkout topic # topic will be the new master\n $ git cherry-pick A C # we want to keep A and C\n\nGot it for this one :)\n\n we now have:\n\n orig master -> A -> B -> C (master)\n\t \\\n\t\t-> D -> E -> F -> A' -> C' (topic)\n\n $ git branch -D master\n\nFor historical reasons, I have to keep my master around so I\nwon't delete it completely. Maybe there is a way to tell that a\nbranch is considered \"dead\" thus indicating there won't be any\nnew developement onto it. I will check this.\n\nAs I have been told privately, what I want in reality is a reset\nof master onto my new HEAD.\n\nI think I have misunderstood reset behaviour.\n\nSo this is how I end up now (from my new master branch):\n\n$ git cherry-pick \n$ git rebase master~NUM\n$ git reset master HEAD\n\nThere I would need something to tell old master is dead but it is\noptionnal (a single tag will do that).\n\nDoes that make sense for you ?\n\nRegards,\n\nP.S: I have problems reading your posts, my mail buffer is full\nof =20 here and there\n-- \nXavier\n"},{"id":"36947","messageId":"20070312194227.GH30489@mad.intersec.eu","threadId":"7204","inReplyTo":"200703121914.l2CJEqW0031669@localhost.localdomain","subject":"Re: What's the best method between merging and rebasing ?","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-03-12T19:42:27Z","receivedAt":"2007-03-12T19:42:27Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Mar 12, 2007 at 08:14:52PM +0100, Xavier Maillard wrote:\n> Hi,\n> \n> From: Pierre Habouzit \n> \n> On Mon, Mar 12, 2007 at 05:34:55PM +0100, Xavier Maillard wrote:\n> \n> > So it seems to be cherry-picks + rebase master on new HEAD but I\n> > am not sure at how things are doing :)\n> \n> okay then I got this right, you don't want to rebase master on new\n> HEAD because you would keep the commits you don't want (I guess). What\n> \n> you start from:\n> \n> orig master -> A -> B -> C (master)\n> \t \\\n> \t\t-> D -> E -> F topic\n> \n> let's say you want to keep A and C from master. here is what I'd do:\n> \n> $ git checkout topic # topic will be the new master\n> $ git cherry-pick A C # we want to keep A and C\n> \n> Got it for this one :)\n> \n> we now have:\n> \n> orig master -> A -> B -> C (master)\n> \t \\\n> \t\t-> D -> E -> F -> A' -> C' (topic)\n> \n> $ git branch -D master\n> \n> For historical reasons, I have to keep my master around so I\n> won't delete it completely. Maybe there is a way to tell that a\n> branch is considered \"dead\" thus indicating there won't be any\n> new developement onto it. I will check this.\n\n git branch -m does that, it renames a branch. so git branch -m master\nold-master does that. it's what I said in my previous mail.\n\n> As I have been told privately, what I want in reality is a reset\n> of master onto my new HEAD.\n> \n> I think I have misunderstood reset behaviour.\n\n the image I use to about \"reset\" is that reset is placing a \"cursor\"\nonto a specific commit. Meaning that if you reset master onto some\n\"commit\" it makes master HEAD be that specicific commit.\n\n the same applies if you do : `git reset HEAD~10' in your working\ncheckout, it places your current HEAD onto HEAD~10. And so on.\n\n> \n> So this is how I end up now (from my new master branch):\n> \n> $ git cherry-pick \n> $ git rebase master~NUM\n> $ git reset master HEAD\n> \n> There I would need something to tell old master is dead but it is\n> optionnal (a single tag will do that).\n before the master you have to:\n\n $ git branch -m master old-master\nand instead of the reset I'd do\n $ git branch master HEAD\nas you don't have any master around after the previous move.\n\n\n\n> P.S: I have problems reading your posts, my mail buffer is full\n> of =20 here and there\n\n that's probable because your MUA does not uderstands quoted printeable\nproperly ? It is advertised correctly in the Content-Transfer-Encodings\nof my mail mimepart so it's not a problem on my end IMHO.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"36948","messageId":"20070312194309.GI30489@mad.intersec.eu","threadId":"7204","inReplyTo":"45F589BF.28E3A5AD@eudaptics.com","subject":"Re: What's the best method between merging and rebasing ?","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-03-12T19:43:09Z","receivedAt":"2007-03-12T19:43:09Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Mar 12, 2007 at 06:11:27PM +0100, Johannes Sixt wrote:\n> Xavier Maillard wrote:\n> > -> D -> E -> F -> several commits from old master -> HEAD (of new master)\n> > \n> > So it seems to be cherry-picks + rebase master on new HEAD but I\n> > am not sure at how things are doing :)\n> \n> Just to get the wording straight: You mean \"reset master to new HEAD\",\n> not \"rebase\". \"reset\" means to point the branch identifier (\"master\") to\n> some commit - with or without modifying the working directory\n> accordingly. OTOH, \"rebase\" means to re-apply a string of commits on top\n> of some other commit.\n \n err that was indeed a lapsus from me. Sorry for the mistake, that was\nindeed what I intended to say.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"}]}