threads / discuss / 27534

Can't get git rebase --onto to work

Subject: Can't get git rebase --onto to work

## tl;dr

10 messages between Jun 2, 2011 and Jun 2, 2011.

replies: 9people: 4as markdown or json

Howard Miller· Jun 2, 2011, 10:17 UTC · lore
Trying to explain this as concisely as possible.
I started with the following branches (names changed to protect the guilty)...
* clientA
* clientB
both have a common ancestry....

I then checked out clientB created a new branch clientB_patch and did a load of work and commits.

However, I actually wanted all those commits to apply to clientA branch instead so....

git checkout clientA git checkout -b clientA_patch (to ensure I didn't wreck original branch) git rebase --onto clientA_patch clientB clientB_patch

It says "rewinding" head and then applies the commits I would have expected.

However, I have now been switched to the 'clientB_patch' branch and it says that it differs from its tracked remote branch by hundreds of commits.

clientA_patch is unchanged. It seems to have mangled clientB_patch and done nothing to clientA_patch. Where did I go wrong?

TIA
Carlos Martín Nieto· Jun 2, 2011, 10:32 UTC · re: Howard Miller · lore

Re: Can't get git rebase --onto to work

On Thu, Jun 02, 2011 at 11:17:41AM +0100, Howard Miller wrote:
Show 18 quoted lines
> Trying to explain this as concisely as possible.
> 
> I started with the following branches (names changed to protect the guilty)...
> 
> * clientA
> * clientB
> 
> both have a common ancestry....
> 
> I then checked out clientB created a new branch clientB_patch and did
> a load of work and commits.
> 
> However, I actually wanted all those commits to apply to clientA
> branch instead so....
> 
> git checkout clientA
> git checkout -b clientA_patch     (to ensure I didn't wreck original branch)
> git rebase --onto clientA_patch clientB clientB_patch

The man page for git-rebase covers this exact situation (around line 88 in my version) . In its case, it's

    git rebase --onto master next topic
which translates to your case as
    git rebase --onto clientA clientB clientB_patch
Cheers,
   cmn
-- 
Carlos Martín Nieto | http://cmartin.tk

"¿Cómo voy a decir bobadas si soy mudo?" -- CACHAI
Howard Miller· Jun 2, 2011, 10:38 UTC · re: Carlos Martín Nieto · lore

Re: Can't get git rebase --onto to work

On 2 June 2011 11:32, Carlos Martín Nieto <carlos@cmartin.tk> wrote:
Show 29 quoted lines
> On Thu, Jun 02, 2011 at 11:17:41AM +0100, Howard Miller wrote:
>> Trying to explain this as concisely as possible.
>>
>> I started with the following branches (names changed to protect the guilty)...
>>
>> * clientA
>> * clientB
>>
>> both have a common ancestry....
>>
>> I then checked out clientB created a new branch clientB_patch and did
>> a load of work and commits.
>>
>> However, I actually wanted all those commits to apply to clientA
>> branch instead so....
>>
>> git checkout clientA
>> git checkout -b clientA_patch     (to ensure I didn't wreck original branch)
>> git rebase --onto clientA_patch clientB clientB_patch
>
> The man page for git-rebase covers this exact situation (around line
> 88 in my version) . In its case, it's
>
>    git rebase --onto master next topic
>
> which translates to your case as
>
>    git rebase --onto clientA clientB clientB_patch
>

Thanks. That's what I said (except I added an extra branch onto ClientA because I interpreted the instructions - wrongly - to say that ClientA would change).

However, I've just realised the bit I missed. I still need to do a (fast forward) merge to get my ClientA_patch branch to actually reflect the changes. I can't help thinking that (although the diagrams are perfectly correct) that a line to the effect in the manpage might have saved some thinking time :)

Tim Guirgies· Jun 2, 2011, 10:38 UTC · re: Howard Miller · lore

Re: Can't get git rebase --onto to work

On Thu, Jun 02, 2011 at 11:17:41AM +0100, Howard Miller wrote:
Show 27 quoted lines
> Trying to explain this as concisely as possible.
> 
> I started with the following branches (names changed to protect the guilty)...
> 
> * clientA
> * clientB
> 
> both have a common ancestry....
> 
> I then checked out clientB created a new branch clientB_patch and did
> a load of work and commits.
> 
> However, I actually wanted all those commits to apply to clientA
> branch instead so....
> 
> git checkout clientA
> git checkout -b clientA_patch     (to ensure I didn't wreck original branch)
> git rebase --onto clientA_patch clientB clientB_patch
> 
> It says "rewinding" head and then applies the commits I would have expected.
> 
> However, I have now been switched to the 'clientB_patch' branch and it
> says that it differs from its tracked remote branch by hundreds of
> commits.
> 
> clientA_patch is unchanged. It seems to have mangled clientB_patch and
> done nothing to clientA_patch. Where did I go wrong?
"--onto clientA_patch"

Please read that out loud. It's meaning in git is the same as in English. What you did was rebase clientB_patch _onto_ clientA_patch. For more information, see "git help rebase".

What you should have done instead:

git checkout -b clientA_patch clientB_patch git rebase -i clientA

What that does is create and then checkout a branch called clientA_patch at the same commit as clientB_patch, then rebase your currently checked out branch (clientA_patch) on top of clientA; the "-i" option allows you double check what's being rebased, as otherwise it would take a whole lot clientB history with it. Simply delete the lines with the commits you don't want.

To fix what you currently have, though, you must do the following. Take heed, however, as I making assumptions that the situation is unchanged from what you described above.

git checkout clientB_patch git reset --hard origin/clientB_patch

I'm assuming your remote is called origin, and also that whatever you pushed last is the latest. If not, you'll have to look at "git reflog" to see which commit to reset the branch to.

Now do:

git checkout clientA_patch git reset --hard clientB_patch git rebase -i clientA

That should give you what you want.
Good luck.
Tim
-- 
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org   - against proprietary attachments
Howard Miller· Jun 2, 2011, 10:43 UTC · re: Tim Guirgies · lore

Re: Can't get git rebase --onto to work

On 2 June 2011 11:38, Tim Guirgies <lt.infiltrator@gmail.com> wrote:
Show 70 quoted lines
> On Thu, Jun 02, 2011 at 11:17:41AM +0100, Howard Miller wrote:
>> Trying to explain this as concisely as possible.
>>
>> I started with the following branches (names changed to protect the guilty)...
>>
>> * clientA
>> * clientB
>>
>> both have a common ancestry....
>>
>> I then checked out clientB created a new branch clientB_patch and did
>> a load of work and commits.
>>
>> However, I actually wanted all those commits to apply to clientA
>> branch instead so....
>>
>> git checkout clientA
>> git checkout -b clientA_patch     (to ensure I didn't wreck original branch)
>> git rebase --onto clientA_patch clientB clientB_patch
>>
>> It says "rewinding" head and then applies the commits I would have expected.
>>
>> However, I have now been switched to the 'clientB_patch' branch and it
>> says that it differs from its tracked remote branch by hundreds of
>> commits.
>>
>> clientA_patch is unchanged. It seems to have mangled clientB_patch and
>> done nothing to clientA_patch. Where did I go wrong?
>
> "--onto clientA_patch"
>
> Please read that out loud.  It's meaning in git is the same as in
> English.  What you did was rebase clientB_patch _onto_ clientA_patch.
> For more information, see "git help rebase".
>
> What you should have done instead:
>
> git checkout -b clientA_patch clientB_patch
> git rebase -i clientA
>
> What that does is create and then checkout a branch called clientA_patch
> at the same commit as clientB_patch, then rebase your currently checked
> out branch (clientA_patch) on top of clientA; the "-i" option allows you
> double check what's being rebased, as otherwise it would take a whole
> lot clientB history with it.  Simply delete the lines with the commits
> you don't want.
>
>
> To fix what you currently have, though, you must do the following.  Take
> heed, however, as I making assumptions that the situation is unchanged
> from what you described above.
>
> git checkout clientB_patch
> git reset --hard origin/clientB_patch
>
> I'm assuming your remote is called origin, and also that whatever you
> pushed last is the latest.  If not, you'll have to look at "git reflog"
> to see which commit to reset the branch to.
>
> Now do:
>
> git checkout clientA_patch
> git reset --hard clientB_patch
> git rebase -i clientA
>
> That should give you what you want.
>
> Good luck.
>
>
Hi Tim,

Thanks for the lengthy post :) As I said in my previous post, I think/hope I have resolved it. I did read the manpage first (I'm not so brave not to before posting here!!) and it did what it said it would. I just misinterpreted it. A final merge was required. I actually picked that up from the "Pro Git" book page which mentions that extra step.

Tim Guirgies· Jun 2, 2011, 10:52 UTC · re: Howard Miller · lore

Re: Can't get git rebase --onto to work

On Thu, Jun 02, 2011 at 11:43:19AM +0100, Howard Miller wrote:
Show 8 quoted lines
> Hi Tim,
> 
> Thanks for the lengthy post :) As I said in my previous post, I
> think/hope I have resolved it. I did read the manpage first (I'm not
> so brave not to before posting here!!) and it did what it said it
> would. I just misinterpreted it. A final merge was required. I
> actually picked that up from the "Pro Git" book page which mentions
> that extra step.
Well, I'm confused, but that'll be due to my ignorance.
As long as you're sorted out.

As for the manpage, though, as someone who read and misunderstood it, do you have any suggestions for its improvements?

Tim
-- 
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org   - against proprietary attachments
Howard Miller· Jun 2, 2011, 10:58 UTC · re: Tim Guirgies · lore

Re: Can't get git rebase --onto to work

On 2 June 2011 11:52, Tim Guirgies <lt.infiltrator@gmail.com> wrote:
Show 11 quoted lines
> On Thu, Jun 02, 2011 at 11:43:19AM +0100, Howard Miller wrote:
>> Hi Tim,
>>
>> Thanks for the lengthy post :) As I said in my previous post, I
>> think/hope I have resolved it. I did read the manpage first (I'm not
>> so brave not to before posting here!!) and it did what it said it
>> would. I just misinterpreted it. A final merge was required. I
>> actually picked that up from the "Pro Git" book page which mentions
>> that extra step.
>
> Well, I'm confused, but that'll be due to my ignorance.
I very much doubt it :) It'll be me failing to explain properly.
Show 5 quoted lines
>
>
> As for the manpage, though, as someone who read and misunderstood it, do
> you have any suggestions for its improvements?
>

The examples are very helpful but it could be a little more explicit which branches are going to get modified by the rebase. Once there are several branches in play it becomes quite a hard think.

Mostly, I just needed a kick to say "look where the branch heads are pointing" (in the example diagrams) before and after the rebase. I don't think I would have got it without the remark in Pro Git that a final merge is required to get the HEADs where I wanted them. Like most things - it's completely obvious when you know.

David· Jun 2, 2011, 11:18 UTC · re: Howard Miller · lore

Re: Can't get git rebase --onto to work

On 2 June 2011 20:58, Howard Miller <howard@e-learndesign.co.uk> wrote:
Show 10 quoted lines
>
> The examples are very helpful but it could be a little more explicit
> which branches are going to get modified by the rebase. Once there are
> several branches in play it becomes quite a hard think.
>
> Mostly, I just needed a kick to say "look where the branch heads are
> pointing" (in the example diagrams) before and after the rebase. I
> don't think I would have got it without the remark in Pro Git that a
> final merge is required to get the HEADs where I wanted them. Like
> most things - it's completely obvious when you know.

If you have a graphical environment, it might help to take a look with 'gitk --all'. Also, if you start it before the rebase, then after the rebase you will need to use its "File>Reload" command to refresh the display.

Tim Guirgies· Jun 2, 2011, 11:18 UTC · re: Howard Miller · lore

Re: Can't get git rebase --onto to work

On Thu, Jun 02, 2011 at 11:58:36AM +0100, Howard Miller wrote:
> On 2 June 2011 11:52, Tim Guirgies <lt.infiltrator@gmail.com> wrote:
> I very much doubt it :) It'll be me failing to explain properly.

I wasn't fishing for compliments; I'm actually confused about that fast-forward merge. Why do you need it? What are you fast-forwarding and where to?

Show 13 quoted lines
> On 2 June 2011 11:52, Tim Guirgies <lt.infiltrator@gmail.com> wrote:
> > As for the manpage, though, as someone who read and misunderstood it, do
> > you have any suggestions for its improvements?
> 
> The examples are very helpful but it could be a little more explicit
> which branches are going to get modified by the rebase. Once there are
> several branches in play it becomes quite a hard think.
> 
> Mostly, I just needed a kick to say "look where the branch heads are
> pointing" (in the example diagrams) before and after the rebase. I
> don't think I would have got it without the remark in Pro Git that a
> final merge is required to get the HEADs where I wanted them. Like
> most things - it's completely obvious when you know.

I'll try to prepare a patch and see if I can improve the wording at all. I'd like you to have a look over it, if you don't mind, and with your recent episode fresh in your mind, review it as if you were reading it in that situation for the first time.

Can you please also point out which section of the doc caused you confusion?

Tim
-- 
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org   - against proprietary attachments
Howard Miller· Jun 2, 2011, 11:28 UTC · re: Tim Guirgies · lore

Re: Can't get git rebase --onto to work

> Can you please also point out which section of the doc caused you
> confusion?
>
>
Ok... this is exactly my situation (and solution)

"First let’s assume your topic is based on branch next. For example, a feature developed in topic depends on some functionality which is found in next.

    o---o---o---o---o  master
         \
          o---o---o---o---o  next
                           \
                            o---o---o  topic
We want to make topic forked from branch master; for example, because
the functionality on which topic depends was merged into the more
stable master branch. We want our tree to look like this:
    o---o---o---o---o  master
        |            \
        |             o'--o'--o'  topic
         \
          o---o---o---o---o  next
We can get this using the following command:
git rebase --onto master next topic"

However, I didn't look at the HEADs (seems stupid now). What I was aiming for was (simply) for 'master' to have the 'topic' branch changes (the delta between next and topic being applied to master if you will). The only outstanding step was to checkout master and merge topic (which will always bee fast-forward, of course).

It's the topic branch that gets rebased - obvious (now) but I interpreted it as the master branch getting modified (--onto master i.e. play the changes 'onto' master and modify master).

I didn't read it carefully enough - makes sense now.

← back to recent threads