Can't get git rebase --onto to work

Can't get git rebase --onto to work

[Howard Miller]

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

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

[Carlos Martín Nieto]

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

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

Cheers,
   cmn
-- 
Carlos Martín Nieto | http://cmartin.tk

"¿Cómo voy a decir bobadas si soy mudo?" -- CACHAI

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

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

[Howard Miller]

On 2 June 2011 11:32, Carlos Martín Nieto <carlos@cmartin.tk> wrote:
> 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 :)

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

[Tim Guirgies]

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

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.


Tim

-- 
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org   - against proprietary attachments

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

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

[Howard Miller]

On 2 June 2011 11:38, Tim Guirgies <lt.infiltrator@gmail.com> wrote:
> 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.

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

[Tim Guirgies]

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

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.

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

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

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

[Howard Miller]

On 2 June 2011 11:52, Tim Guirgies <lt.infiltrator@gmail.com> wrote:
> 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.

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

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

[David]

On 2 June 2011 20:58, Howard Miller <howard@e-learndesign.co.uk> wrote:
>
> 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.

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

[Tim Guirgies]

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

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?

> 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

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

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

[Howard Miller]

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