2

I have a feature branch that I want to interactively rebase on master, like:

A - B - C - D (master)
     \
      E - F (feature)

The desired result is

A - B - C - D (master) - E - F (feature)

with some sanity-check scripts running after E and F (using exec lines on the rebase-todo file).

However, if I go to magit's log buffer and type r e with the point on commit D, magit performs a git rebase -i D^ instead of git rebase -i D, so the feature's commits are replayed from C. What I want is to rebase onto the tip of master, not onto master^.

So:

  1. Is there a way to force magit to base the interactive rebase on D, where I'm pointing at in the log buffer, and not on the parent of where I'm pointing?
  2. magit doesn't seem to do this automatic appending of ^ in non-interactive rebases. Why the discrepancy? Is cross-branch interactive rebase somehow a bad idea?

BTW, I know there are workarounds: I can drop down to the command line; I can split this into an intra-branch interactive rebase followed by a non-interactive one; or I can do a dummy commit on master. None of them is very convenient. What I'd like to know is if there's a way to do it in one step, or if not, whether there's some wisdom behind it that I should know about.

Jun Inoue
  • 544
  • 1
  • 4
  • 9

1 Answers1

1

In Git one has to select the commit before the first commit one wants to rebase. In Magit one has to select the first commit one wants to rebase. It's as simple as that - select the first commit you want to rebase.

Q: Why does one of to select the "prior commit" in Git?

A: Because that's how FROM..TO is interpreted in all of Git. FROM is exclusive and TO inclusive. From a "language" perspective that makes sense.

Q: Why isn't it the same in Magit?

A: Because that wouldn't make much sense given Magit's UI. "To select X you have to select Y, because it comes before X" is a bit strange.

It also would make it harder to start a rebase in some cases. E.g. the status buffer lists unpushed commits. To interactively rebase some of these commits move to the first commit which is to be rebased and r e. The first commit to be rebased could be the first unpushed commit. If you had to select the commit "before that", then that would not be easily possible from the status buffer, because the "last commit which was pushed" isn't part of the "commits that haven't been pushed yet" and therefore isn't listed as such. Instead you would have to show the complete log (l l) in a separate buffer, move to the commit, start the rebase, and then quit the log buffer to get back to the status buffer where the information about the ongoing rebase is being displayed.

Also you are using the wrong command to "transplant" a branch onto another. Instead use r r. If master is properly configured as feature's upstream, then that would be offered as default choice for the branch to rebase the current branch onto.

tarsius
  • 8,147
  • 5
  • 32
  • 46