The message:
fatal: Not possible to fast-forward, aborting.
means that you've told Git to use --ff-only
for the merge that occurs as the second step of git pull
1 and that this merge cannot be done as a fast-forward.
There was a bug in Git 2.33 where --ff-only
misbehaved in certain cases:
* "git pull --ff-only" and "git pull --rebase --ff-only" should make
it a no-op to attempt pulling from a remote that is behind us, but
instead the command errored out by saying it was impossible to
fast-forward, which may technically be true, but not a useful thing
to diagnose as an error. This has been corrected.
(merge 361cb52383 jc/fix-pull-ff-only-when-already-up-to-date later to maint).
If you have this version of Git, you should upgrade to 2.34 or later. Your comment implies that you've hit this particular bug.
(Your comment about Bitbucket almost certainly involves something else entirely, and is a Bitbucket issue, not a Git one.)
1Remember that git pull
is a convenience short-cut that means:
- run
git fetch
;
- run a second Git command to do something with the commits obtained in step 1.
The default second command is git merge
but you can choose git rebase
instead. The --ff-only
option is an option to git merge
and means nothing to git rebase
, so git pull
won't supply --ff-only
to the second command if you choose git rebase
(but it is supposed to stop the rebase for that case). Whether git merge
supplies --ff-only
to the second command if you choose git merge
depends on how you configure git pull
to operate.