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

[Johannes Sixt <j.sixt@viscovery.net>]

Am 4/12/2010 16:09, schrieb Eugene Sajine:
> esajine@ESAJINEWWW /c/git_repos/test2 (topic)
> $ git rebase master
> Current branch topic is up to date.
> <======= Really? Topic is actually based on next – what does this "up
> to date" mean??

Why should rebase bother? The difference between master and topic are
*two* commits. Since these two are already on top of master in linear
history, you get no advantage by doing a rebase operation. Therefore, you
see "already up to date".

The fact that the second commit from the tip of topic is also labeled
"next" is absolutely irrelevant to rebase. rebase only looks at the refs
that you tell it about: master and topic (implicitly pointed to by HEAD),
nothing else.

What you really want to do, obviously, is:

   git rebase --onto master next topic

No, there is no shorter form to spell this operation.

> esajine@ESAJINEWWW /c/git_repos/test2 (topic)
> $ git rebase -i --onto master topic
> Successfully rebased and updated refs/heads/topic. <=== BUG – here it
> printed me “noop” in file to edit, when I exited it should do nothing,
> but it still did something and I double checked it.

Not a bug.

Your command is the same as

   git rebase -i --onto master topic topic

because you are already on branch topic. Since there are no commits in the
range topic..topic, rebase -i told you "noop". This word is perhaps poorly
chosen, because it does not mean "no operation"[*], but "there are no
commits to transfer". But branch 'topic' that you gave as the last
argument (or implicitly by being at branch 'topic') is still transferred
--onto master. This explains the result that you observed.

Of course, if you do not 'reset --hard topic@{1}' at this point, you will
ultimately lose the commits on branch topic.

[*] You can get "no operation" by deleting the line "noop".

-- Hannes