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

From: Jeff King <peff@peff.net>
Date: Apr 11, 2010, 10:22 UTC
Message-ID: <20100411102255.GB20484@coredump.intra.peff.net>
In-Reply-To: <h2x76c5b8581004101510hc1d15f42u7e48dafbc275c998@mail.gmail.com>

On Sat, Apr 10, 2010 at 06:10:53PM -0400, Eugene Sajine wrote:

Show 5 quoted lines

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

But in "git rebase --onto master topic", the relationship between master and topic is irrelevant. It is the same as:

  git rebase --onto master topic HEAD

which will consider the range between topic and HEAD as the set of commits to rebase.

Did you want to do:

  git rebase --onto master next topic

? That would take the commits between next and topic (i.e., just "topic" in your example), and rebuild them on top of master.

Show 8 quoted lines

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

That's not the result I get. The non-interactive rebase _does_ do the same thing. Try this:

  mkdir repo
  cd repo
  git init

  echo content >>file && git add file && git commit -m one
  git checkout -b next
  echo content >>file && git add file && git commit -m two
  git checkout -b topic
  echo content >>file && git add file && git commit -m three

  git rebase --onto master topic

You will see that "topic" has been reset back to commit one, the same as master.

If that was not happening before, it was likely because you were not actually on the "topic" branch before. So who knows what the implicit "HEAD" argument referred to.

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

I don't think it does, as shown by my example above. If you still think so, please create a short test case that demonstrates the difference.

-Peff