Re: git rebase command and docs questions

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 9, 2010, 21:11 UTC
Message-ID: <7vhbnk1gc6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <r2mfabb9a1e1004091337w8ec2b721y3a5082d5e0f5925c@mail.gmail.com>

Sverre Rabbelier <srabbelier@gmail.com> writes:

Show 11 quoted lines

> On Fri, Apr 9, 2010 at 20:49, Eugene Sajine <euguess@gmail.com> wrote:
>> But, in “git rebase –onto master next topic” the meaning of the “next
>> topic” parameters is different: as I understand, it actually specifies
>> a range of commits from next to topic,  because –onto changes the way
>> the whole command is working, but it is not clarified in help. Is that
>> correct understanding?
>
> I've never been able to remember how rebase --onto works, perhaps if
> we actually let users specify a range it would be more intuitive?
>
> $ git rebase next..topic master

Hmm, re*base* means "change the base to _this one_"; the above is more like "replay these on master", which is often a useful operation but is different.

Suppose other people have worked on the project and made their pushes since you started working on your changes:

      o---o master
     /
 ---o---o---o---o origin

"git rebase origin" asks "I know my current work is based on a tad stale state, and I'd prefer a linear history, so change the base to origin".

If the thing of whose base you want to change is not your "current work", then you name that explicitly, i.e. "git rebase origin master" (i.e. the second branch name defaults to HEAD as usual).

Onto is an optional feature that is primarily for correcting your earlier mistakes. Notice in the above picture, other people doing parallel work and pushing their changes out is part of the normal life of distributed development; there is no mistake on your part involved.

But suppose you started building bugfixes in a topic forked from origin, but after that you realize they should be based on origin/maint:

                   X---Y fixes
                  /
         o---o---o---o---o origin
        /
    ---o---o---o origin/maint

You could have made fixes branch that houses X and Y on origin/maint (and later merge that to master to be pushed to origin), but you did not have perfect foresight. You do not obviously want to change the base of whole 'fixes' branch to 'origin/maint', as that will pull in changes in origin that are not related to your fixes.

You would want to rebase 'fixes' branch (whose fork point can be specified with 'origin') but not on top of 'origin', but on 'origin/maint'. Hence instead of running "git rebase origin" to produce

                           X'--Y' fixes
                          /
         o---o---o---o---o origin
        /
    ---o---o---o origin/maint

You would say "git rebase --onto origin/maint origin" to transplant X' and Y' as if you started working from 'origin/maint':

         o---o---o---o---o origin
        /
    ---o---o---o origin/maint
                \
                 X'--Y' fixes

If you _had_ your "replay" command, the workflow for this would be:

    $ git checkout -b maint-fixes origin/maint
    $ git replay origin..fixes

Before somebody else makes useless noises, "cherry-pick" could be a good command in the existing UI set to do that kind of thing.