Re: git rebase command and docs questions

From: Eugene Sajine <euguess@gmail.com>
Date: Apr 10, 2010, 22:30 UTC
Message-ID: <s2l76c5b8581004101530h171f3c2dv6a2fc9d4225fbd4e@mail.gmail.com>
In-Reply-To: <l2nfabb9a1e1004091423te78b692btd8bbb03785f94a16@mail.gmail.com>

On Fri, Apr 9, 2010 at 5:23 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:

Show 8 quoted lines

> Heya,
>
> On Fri, Apr 9, 2010 at 23:11, Junio C Hamano <gitster@pobox.com> wrote:
>> 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.
>
> Yes, I guess that's true.

I'm a bit confused. Isn't the rebase actually replaying the commits one by one starting from new base instead of old one? I believe it does apply diffs one by one, else there would be no conflicts during rebase whatsoever. Secondly, git complains about range not specified if you will try to execute something like

git rebase --onto  master topic

when topic is not direct descendant of master. Git will say "not a range".

So, That's why i make a conclusion that the real meaning of

git rebase --onto master next topic

is very close if not exactly matching the

git rebase --onto master next..topic

Show 30 quoted lines

>
>> If you _had_ your "replay" command, the workflow for this would be:
>>
>>    $ git checkout -b maint-fixes origin/maint
>>    $ git replay origin..fixes
>
> True again.
>Yep therefore the interface
>
>> Before somebody else makes useless noises, "cherry-pick" could be a good
>> command in the existing UI set to do that kind of thing.
>
> I still think the UI for --onto is awkward. At the very least it should be:
>
> git rebase --fork-at=origin origin/maint fixes
>
> Or something like that. Since currently you suddenly have to specify
> an argument to --onto that was previously positional. Does that make
> sense?
>
> Case 1:
> git rebase origin fixes
> git rebase <new_base> <tip>
>
> Case 2:
> git rebase --onto origin/maint origin fixes
> git rebase --onto=<new_base> <fork_point> <tip>
>
> I know that in the --onto case <new_base> is not an argument to
> --onto, but that's what it looks/feels like.

How is that possible that it is not an argument to --onto???

from docs:

SYNOPSIS

git rebase [-i | --interactive] [options] [--onto <newbase>]
        <upstream> [<branch>]
git rebase [-i | --interactive] [options] --onto <newbase>
        --root [<branch>]
git rebase --continue | --skip | --abort

When i'm executing git rebase --onto master next topic

master is exactly the new base, new fork point for topic, which was previously forked from next!

Show 13 quoted lines

>Said differently, it's
> just _really weird_ that a new argument (for a different mode) shows
> up between two other arguments. It should either be at the beginning,
> or at the end, but in the middle is just awkward, no?
>
> So another solution might be to change the position of the
> <fork_point> in the --onto case.
>
> --
> Cheers,
>
> Sverre Rabbelier
>