git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Johannes Sixt <j.sixt@viscovery.net>
Date
Apr 12, 2010, 15:13 UTC
Message-ID
<4BC3389C.4090807@viscovery.net>
In-Reply-To
<q2z76c5b8581004120709t860ff112i5dd057327b94ad0e@mail.gmail.com>
Am 4/12/2010 16:09, schrieb Eugene Sajine:
Show 5 quoted lines
> 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.
Show 5 quoted lines
> 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
Previous: Eugene SajineNext: Eugene Sajine
Message 15 of 19 in “[BUG] - git rebase -i performs rebase when it shouldn't?”
  1. Eugene SajineApr 9, 2010
  2. Jeff KingApr 10, 2010
  3. Junio C HamanoApr 10, 2010
  4. Jeff KingApr 10, 2010
  5. Johannes SixtApr 10, 2010
  6. Jeff KingApr 11, 2010
  7. Johannes SixtApr 11, 2010
  8. Jeff KingApr 12, 2010
  9. Michal VitecekApr 12, 2010
  10. Johannes SixtApr 12, 2010
  11. Eugene SajineApr 10, 2010
  12. Jeff KingApr 11, 2010
  13. Eugene SajineApr 11, 2010
  14. Eugene SajineApr 12, 2010
  15. Johannes SixtApr 12, 2010
  16. Eugene SajineApr 12, 2010
  17. Johannes SixtApr 12, 2010
  18. Eugene SajineApr 13, 2010
  19. Johannes SixtApr 14, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.