Re: git rebase command and docs questions

From: Sverre Rabbelier <srabbelier@gmail.com>
Date: Apr 9, 2010, 21:23 UTC
Message-ID: <l2nfabb9a1e1004091423te78b692btd8bbb03785f94a16@mail.gmail.com>
In-Reply-To: <7vhbnk1gc6.fsf@alter.siamese.dyndns.org>

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.

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

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