What does `git rebase –fork-point master` mean?
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
git rebase docs but don’t quite understand why it didn’t lead to my expected result. Can someone explain it please?
It didn’t lead to your expected result because
--fork-point has nothing to do with deciding the base for the new commits.
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).
 – 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.
Answered By – Mark Adelsberger