What does `git rebase --fork-point master` mean?

Question

My use case is changing my commits in a feature branch before I publish it, e.g., reword commit messages, squash some commits, etc. I do not want to move the commits to a new base.

For this, I usually do something like this:

git rebase -i HEAD~4

where the number "4" is the result of manually counting the commits in my feature branch.

I was wondering if Git has a command like "start interactive rebase for all commits in my feature branch but don't move then to a newer master – just stay where you are". I found the --fork-point option of git rebase and tried this:

git rebase -i --fork-point master

However, this doesn't have any noticeable effect and behaves the same as git rebase -i master.

Instead, this does what I need:

git rebase -i $(git merge-base --fork-point master)

I read the docs of --fork-point in git rebase docs but don't quite understand why it didn't lead to my expected result. Can someone explain it please?

Answer 1

It didn't lead to your expected result because --fork-point has nothing to do with deciding the base for the new commits[1].

So the default is to base the new commits at the upstream (master in this case), and --fork-point doesn't affect that.

(For reference, what --fork-point does is, it uses the reflogs to refine the calculation that "guesses" what commits should be rewritten. This is not always - or, in my experience, even often - very useful.)

Your two options are to use the merge base as the upstream - as you describe - or use the --onto option to explicitly set the new base (in this case, setting it to match the original base).

---

[1] - remember that even though conceptually you're editing commits, really rebase always writes new commits - except when it does nothing. So when it 'edits' a commit, it really creates new commits that are similar to old commits, but edited.