Re: [BUG] - git rebase -i performs rebase when it shouldn't?

[Eugene Sajine <euguess@gmail.com>]

On Sat, Apr 10, 2010 at 12:26 AM, Jeff King <peff@peff.net> wrote:
> On Fri, Apr 09, 2010 at 03:35:42PM -0400, Eugene Sajine wrote:
>
>> In case of this situation
>>
>>        A  master
>>         \
>>          B  next
>>           \
>>            C  topic
>>
>>
>> $ git rebase --onto master topic
>> First, rewinding head to replay your work on top of it...
>> fatal: Not a range.
>> Nothing to do.
>>
>> Which is OK.
>
> I think this doesn't do quite what you thought. It's true there is
> "nothing to do" as in "nothing to apply", but it _did_ in fact rewind
> topic back to "master".
>
> You seem to be thinking that
>
>  git rebase --onto master topic
>
> means "rebase everything from master to topic onto master". It doesn't.
> That would be:
>
>  git rebase master topic
>
> or, if you are already on topic, just
>
>  git rebase master.
>
> The "--onto" option takes an argument, which says "put the commits on
> top of here, even though it was not the upstream base otherwise
> specified". So what your command does is say "using the current branch
> (which is topic), take everything built on top of topic (which is
> nothing), and rebuild it on top of master".

Actually no, i was not thinking about what you think i was;). What i
was trying to understand with this command (git rebase --onto master
topic) is the
behavior of the system when the topic branch is indirect descendant of
the master and the direct parent of topic (next) is omitted, skipped.

In this situatiion

git rebase master topic

does not work (see thread "git rebase command and docs questions") p1.

So, once again i think that the interface in this case worked properly:

as topic is not direct descendant, master option value goes to --onto
and there is no range defined properly.
Therefore the command worked ok, when it refused to do anything.

Now the problem i have is that:

git rebase -i --onto master topic

actually worked and did something, what i would not expect it to do.

So, the problem is: non-interactive rebase DOES NOT execute the
command, interactive DOES execute.

>
> So no, it's not a bug. Yes, it's a terrible interface. There is really
> no reason IMHO for rebase to take a "which branch to operate on"
> argument at all. It should just operate on HEAD, like merge does. If you
> want to merge on a different branch, you "git checkout" that branch
> first.

The bug is in the fact that rebase works differently in interactive
and non-interactive variants.

Thanks,
Eugene