{"thread":{"id":"22037","subject":"Need some help with git rebase","startedAt":"2009-12-28T13:33:27Z","lastAt":"2009-12-31T11:06:01Z","messageCount":7,"participants":["Sylvain RABOT","Sylvain Rabot","Wincent Colaiuta","Tay Ray Chuan","Peter Baumann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"130397","messageId":"4B38B3A7.6010900@steek.com","threadId":"22037","inReplyTo":null,"subject":"Need some help with git rebase","fromName":"Sylvain RABOT","fromEmail":"srabot@steek.com","sentAt":"2009-12-28T13:33:27Z","receivedAt":"2009-12-28T13:33:27Z","isPatch":false,"sender":{"key":"srabot@steek.com","avatar":null},"body":"Hello everybody,\n\nI'm trying to backport a feature branch which is based on the master \nbranch into another branch also based on master but older :\n\n a--a--a--a--a--a--a--a--a feature\n /\n--x--x--x--x--x--x--x--x--x--x--x--x master\n \\\n o--o--o--o--o--o--o 12.72.1\n \n \nThis is what I would like :\n \n \n a--a--a--a--a--a--a--a--a feature\n /\n--x--x--x--x--x--x--x--x--x--x--x--x master\n \\\n o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a 12.72.1\n \n\nAnd this is what I get with git rebase --onto 12.72.1 master feature\n \n o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a feature\n /\n--x--x--x--x--x--x--x--x--x--x--x--x master\n \\\n o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a 12.72.1\n\nCan you exlain to me what I need to do to get what I expect.\n\nBest regards.\n\n-- \nSylvain\n"},{"id":"130583","messageId":"1262211866.7068.1.camel@kheops","threadId":"22037","inReplyTo":"4B38B3A7.6010900@steek.com","subject":"Re: Need some help with git rebase","fromName":"Sylvain Rabot","fromEmail":"sylvain@abstraction.fr","sentAt":"2009-12-30T22:24:26Z","receivedAt":"2009-12-30T22:24:26Z","isPatch":false,"sender":{"key":"sylvain@abstraction.fr","avatar":"https://avatars.githubusercontent.com/u/153052?v=4"},"body":"So,\n\nI tried again \"git rebase --onto 12.72.1 master feature\".\n\nSituation :\n\n a--a--a--a--a--a--a--a--a feature\n /\n--x--x--x--x--x--x--x--x--x--x--x--x master\n \\\n o--o--o--o--o--o--o 12.72.1\n\n\nWork flow :\n\n$ git checkout 12.72.1\n$ git rebase --onto 12.72.1 master feature\n\na lot of conflicts, resolving and git rebase --continue\n\nAnd then, at the end of the rebase, without me doing anything, feature\nbranch is checked out and it seems that its HEAD has been reset to the\nnew 12.72.1 HEAD.\n\n--x--x--x--x--x--x--x--x--x--x--x--x master\n \\\n o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a 12.72.1 feature\n\nIs that normal ? If it is, how do I do to avoid my feature branch to be\nreset at 12.72.1's HEAD ?\n\nAny enlightenment is very welcome.\n\nRegards.\n\n-- \nSylvain Rabot \n"},{"id":"130584","messageId":"CB5B49CA-0C66-4384-9B47-3675E517E203@wincent.com","threadId":"22037","inReplyTo":"1262211866.7068.1.camel@kheops","subject":"Re: Need some help with git rebase","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-12-30T22:46:24Z","receivedAt":"2009-12-30T22:46:24Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 30/12/2009, a las 23:24, Sylvain Rabot escribió:\n\n> So,\n>\n> I tried again \"git rebase --onto 12.72.1 master feature\".\n>\n> Situation :\n>\n> a--a--a--a--a--a--a--a--a feature\n> /\n> --x--x--x--x--x--x--x--x--x--x--x--x master\n> \\\n> o--o--o--o--o--o--o 12.72.1\n>\n>\n> Work flow :\n>\n> $ git checkout 12.72.1\n> $ git rebase --onto 12.72.1 master feature\n>\n> a lot of conflicts, resolving and git rebase --continue\n>\n> And then, at the end of the rebase, without me doing anything, feature\n> branch is checked out and it seems that its HEAD has been reset to the\n> new 12.72.1 HEAD.\n>\n> --x--x--x--x--x--x--x--x--x--x--x--x master\n> \\\n> o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a 12.72.1 feature\n>\n> Is that normal ? If it is, how do I do to avoid my feature branch to \n> be\n> reset at 12.72.1's HEAD ?\n>\n> Any enlightenment is very welcome.\n\nLook at the \"git-rebase\" man page, particularly the order of the \narguments, what they mean, and the usage examples of \"--onto\":\n\n $ git rebase --onto 12.72.1 master feature\n\nMeans, \"replay these changes on top of 12.72.1\", where \"these changes\" \nrefers to commits on branch \"feature\" with upstream \"master\", which is \nwhat \"git rebase\" did for you.\n\nIf you actually want the \"feature\" branch to continue pointing at the \nold feature branch rather than your newly rebased one, you could just \nlook up the old SHA1 for it and update it with:\n\n $ git branch -f feature abcd1234\n\nWhere \"abcd1234\" is the hash of the old \"feature\" HEAD.\n\nBut I don't really know why you'd want to do that. The purpose of \"git \nrebase\" isn't to copy or cherry-pick commits from one branch onto \nanother, but to actually _move_ (or transplant, or replay, if you \nprefer) those commits.\n\nMaybe I misunderstood your intentions though.\n\nCheers,\nWincent\n"},{"id":"130588","messageId":"be6fef0d0912302101ta010dfamab05b751a0ceee76@mail.gmail.com","threadId":"22037","inReplyTo":"1262211866.7068.1.camel@kheops","subject":"Re: Need some help with git rebase","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2009-12-31T05:01:00Z","receivedAt":"2009-12-31T05:01:00Z","isPatch":false,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\nOn Thu, Dec 31, 2009 at 6:24 AM, Sylvain Rabot wrote:\n> And then, at the end of the rebase, without me doing anything, feature\n> branch is checked out and it seems that its HEAD has been reset to the\n> new 12.72.1 HEAD.\n>\n> --x--x--x--x--x--x--x--x--x--x--x--x master\n>   \\\n>    o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a 12.72.1 feature\n>\n> Is that normal ? If it is, how do I do to avoid my feature branch to be\n> reset at 12.72.1's HEAD ?\n\nreading the manual, I think this is normal.\n\nAccording to the third paragraph of the description of git-rebase, the\nbranch feature will be reset to 12.72.1.\n\nYou can just rename the branch back to 12.72.1, and retrieve the old\ntip of feature by examining the reflog.\n\n-- \nCheers,\nRay Chuan\n"},{"id":"130595","messageId":"7fce93be0912310102x53755120o31e42c4a7a92a709@mail.gmail.com","threadId":"22037","inReplyTo":"CB5B49CA-0C66-4384-9B47-3675E517E203@wincent.com","subject":"Re: Need some help with git rebase","fromName":"Sylvain Rabot","fromEmail":"sylvain@abstraction.fr","sentAt":"2009-12-31T09:02:12Z","receivedAt":"2009-12-31T09:02:12Z","isPatch":false,"sender":{"key":"sylvain@abstraction.fr","avatar":"https://avatars.githubusercontent.com/u/153052?v=4"},"body":"On Wed, Dec 30, 2009 at 23:46, Wincent Colaiuta  wrote:\n>\n> Look at the \"git-rebase\" man page, particularly the order of the arguments, what they mean, and the usage examples of \"--onto\":\n>\n>  $ git rebase --onto 12.72.1 master feature\n>\n> Means, \"replay these changes on top of 12.72.1\", where \"these changes\" refers to commits on branch \"feature\" with upstream \"master\", which is what \"git rebase\" did for you.\n>\n> If you actually want the \"feature\" branch to continue pointing at the old feature branch rather than your newly rebased one, you could just look up the old SHA1 for it and update it with:\n>\n>  $ git branch -f feature abcd1234\n>\n> Where \"abcd1234\" is the hash of the old \"feature\" HEAD.\n>\n> But I don't really know why you'd want to do that. The purpose of \"git rebase\" isn't to copy or cherry-pick commits from one branch onto another, but to actually _move_ (or transplant, or replay, if you prefer) those commits.\n>\n> Maybe I misunderstood your intentions though.\n>\n> Cheers,\n> Wincent\n>\n\nIn fact I want to backport the commits of the feature branch into 12.72.1.\nI used git rebase because the drawings of the man page looked like\nthat I wanted to do and it does except for the part it resets the head\nof my feature branch.\n\nBut the good behavior would be to cherry pick each commit of the\nfeature branch and apply them into 12.72.1, right ?\n\nThanks for your answer.\n\nRegards.\n\n--\nSylvain\n"},{"id":"130596","messageId":"20091231093200.GB24460@m62s10.vlinux.de","threadId":"22037","inReplyTo":"7fce93be0912310102x53755120o31e42c4a7a92a709@mail.gmail.com","subject":"Re: Need some help with git rebase","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2009-12-31T09:32:00Z","receivedAt":"2009-12-31T09:32:00Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Thu, Dec 31, 2009 at 10:02:12AM +0100, Sylvain Rabot wrote:\n> On Wed, Dec 30, 2009 at 23:46, Wincent Colaiuta  wrote:\n> >\n> > Look at the \"git-rebase\" man page, particularly the order of the arguments, what they mean, and the usage examples of \"--onto\":\n> >\n> >  $ git rebase --onto 12.72.1 master feature\n> >\n> > Means, \"replay these changes on top of 12.72.1\", where \"these changes\" refers to commits on branch \"feature\" with upstream \"master\", which is what \"git rebase\" did for you.\n> >\n> > If you actually want the \"feature\" branch to continue pointing at the old feature branch rather than your newly rebased one, you could just look up the old SHA1 for it and update it with:\n> >\n> >  $ git branch -f feature abcd1234\n> >\n> > Where \"abcd1234\" is the hash of the old \"feature\" HEAD.\n> >\n> > But I don't really know why you'd want to do that. The purpose of \"git rebase\" isn't to copy or cherry-pick commits from one branch onto another, but to actually _move_ (or transplant, or replay, if you prefer) those commits.\n> >\n> > Maybe I misunderstood your intentions though.\n> >\n> > Cheers,\n> > Wincent\n> >\n> \n> In fact I want to backport the commits of the feature branch into 12.72.1.\n> I used git rebase because the drawings of the man page looked like\n> that I wanted to do and it does except for the part it resets the head\n> of my feature branch.\n> \n> But the good behavior would be to cherry pick each commit of the\n> feature branch and apply them into 12.72.1, right ?\n> \n\n$ git checkout -b rebased_feature feature\n$ git rebase --onto 12.72.1 master rebased_feature\n\nwill create a temporary branch named \"rebased_feature\" pointing to the same\ncommit as the branch \"feature\". In fact, this will rebase the commits on the\nfeature branch not reachable from master onto your 12.72.1 branch *and* won't\nreset the feature branch. Instead the temporary branch named \"rebased_feature\"\nwill be rebased ontop of 12.72.1.\n\nI would still prefere the rebase over doing multiple cherry picks.\n\n-Peter\n"},{"id":"130602","messageId":"89AAB33C-89D4-46E9-A950-1CBFB4D2CBB3@wincent.com","threadId":"22037","inReplyTo":"7fce93be0912301502r77152c52sbccf762fb6c44610@mail.gmail.com","subject":"Re: Need some help with git rebase","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-12-31T11:06:01Z","receivedAt":"2009-12-31T11:06:01Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 31/12/2009, a las 00:02, Sylvain Rabot escribió:\n\n> In fact I want to backport the commits of the feature branch into \n> 12.72.1.\n>\n> I used git rebase because the drawings of the man page looked like \n> that I\n> wanted to do and it does except for the part it resets the head of my\n> feature branch.\n>\n> But as you said the good behavior would be to cherry pick each \n> commit of the\n> feature branch and apply them into 12.72.1, right ?\n\nWell rebasing is just a convenient way of cherry-picking a bunch of \ncommits, so it's probably the right tool for the job.\n\nBut as you've seen, it has the effect of \"moving\" or \"transplanting\" \nthe feature branch (replacing the old feature HEAD). If you really \nwant the original feature branch HEAD to continue existing after the \nrebase you'll need to take some specific action to preserve it \nbeforehand (creating a temporary branch before doing the rebase like \nPeter Baumann suggested) or restore it afterwards (using \"git branch\" \nlike I suggested).\n\nBut before you actually do that, I'd make sure that you actually have \na valid reason for keeping that branch around. Maybe wanting to \n\"backport\" those commits onto various different branches might be a \nvalid reason. But it's worth thinking through because Git gives you \nvarious tools for supporting different workflows (merging, rebasing, \ncherry-picking) and they each have their use cases.\n\nCheers,\nWincent\n"}]}