Git 2.34 has changed how you configure fast-forward only pulls and rebasing
I'll start with the conclusion and give you the story afterward.
Before Git 2.34, if you were tracking upstream repositories and
perhaps carrying local changes on top,
it was sensible to configure '
pull.ff only' globally (in your
~/.gitconfig) to stop '
git pull' from warning you and then set
pull.rebase true' in repositories that you had local changes in.
As of Git 2.34, this causes a plain '
git pull' to abort in any
repository that has local changes. The simplest fix is to also set
git config pull.ff true'
in each repository where you've set pull.rebase. This may become
unnecessary in some future Git version, because the Git 2.34 behavior
may be a bug.
When Git started out, '
defaulted to trying to fast-forward what had been fetched and then
automatically doing a merge if it wasn't possible (basically to
git pull -ff', although I'm not sure they're exactly the same).
In theory this was what you wanted as a developer; in practice it
was easy to get surprise merges that you didn't want in various
situations. Soon people began suggesting that you use '
--ff-only' or better yet, configure '
pull.ff only' through
config. At a certain point,
the Git developers themselves decided this wasn't the greatest
default and began having '
git pull' warn about it and ask you
to do something about it (cf).
I started out setting '
pull.ff only' on some repositories as part
of my multi-repo workflow or tracking
some upstreams. When Git started warning
about plain '
git pull' with nothing configured, I upgraded this
to a global setting of '
pull.ff only' in my ~/.gitconfig, since
I didn't have any repositories where I want to automatically pull
and merge. Almost always I'm either exactly tracking an upstream
(where I'm going to reset to origin/main if the upstream does
something weird) or I'm carrying local changes that I want to
automatically rebase on top of the new
upstream. For a long time this worked fine, and then I updated to
the Fedora 34 version of Git 2.34.1 and suddenly my automatic
rebasing on pulls broke (you can read an example in my Fedora bug
As of Git 2.34, two things have changed. First, the default behavior
of 'git pull' is now to abort if it can't fast-forward the upstream
into your local branch (ie, '
git pull --ff-only'); basically,
the previous warning has become an error.
Second, the configuration setting of '
pull.ff only' now takes
priority over '
pull.rebase true' (although not over an explicit
--rebase on the command line). If you have both in a repository
with things to rebase, you effectively wind up running '
--ff-only', which fails because you have additional local changes
that Git thinks would have to be merged. The behavior of 'pull.ff
only' here may be an accidental bug and is certainly not historical
behavior, but we have to deal with the Git release we get, not the
one we'd like.
(This isn't explicitly documented in the release notes (also),
although they do talk about a general overhaul of this area.
The 2.34 manual pages are not the clearest about the behavior
and they don't explicitly say that 'pull.ff only' takes priority,
git pull manpage somewhat implies that --ff-only
conflicts with --rebase.)
As far as I can see, I have two options to get the behavior I want.
First, I can continue to set '
pull.ff only' globally, for safety,
and then set '
pull.ff true' in any repository where I also set
pull.rebase true'. I'm not sure that this is completely harmless
in old versions of Git, though. The other option, if I'm only going
to be using Git 2.34 and later and I trust Git not to make any
surprising changes here, is to not set
pull.ff globally and set
pull.rebase true' in my 'I have changes on top of upstream'
repositories that I want to automatically rebase on pulls.
(I've tested both approaches and they appear to work. Carefully
reading the Git source code confirms that '
git pull --ff-only'
is basically the default, although it's not actually implemented
quite that way. See builtin/pull.c for the
PS: A nice long history of the changes in this area in 'git pull' from 2020 or so onward is here. There have been a number of steps. The history has already been updated a bit for Git 2.35 and may be updated more in the future, so check in on it for the latest news.