After a git pull origin master
, I get the following message:
warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:
git config pull.rebase false # merge (the default strategy)
git config pull.rebase true # rebase
git config pull.ff only # fast-forward only
You can replace "git config" with "git config --global" to set a default
preference for all repositories. You can also pass --rebase, --no-rebase,
or --ff-only on the command line to override the configured default per
invocation.
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), 51.49 KiB | 850.00 KiB/s, done.
The pull seems successful, but I am unsure.
What can I do to fix this?
In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.
When you do a git pull origin master
,
git pull
performs a merge, which often creates a merge commit. Therefore, by default, pulling from the remote is not a harmless operation: it can create a new commit SHA hash value that didn’t exist before. This behavior can confuse a user, because what feels like it should be a harmless download operation actually changes the commit history in unpredictable ways.
To avoid this, you need
git pull --ff-only
(or not? read on to see which one fits your requirements)
With git pull --ff-only
, Git will update your branch only if it can be “fast-forwarded” without creating new commits. If this can’t be done, git pull --ff-only
simply aborts with an error message.
You can configure your Git client to always use --ff-only
by default, so you get this behavior even if you forget the command-line flag:
git config --global pull.ff only
Note: The --global
flag applies the change for all repositories on your machine. If you want this behaviour only for the repository you're in, omit the flag.
Taken from here
This warning was added in Git 2.27.
This is what the complete warning looks like:
Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull:
git config pull.rebase false # merge (the default strategy)
git config pull.rebase true # rebase
git config pull.ff only # fast-forward only
You can replace "git config" with "git config --global" to set a default preference for all repositories. You can also pass --rebase, --no-rebase, or --ff-only on the command line to override the configured default per invocation.
The warning presents three commands as options, all of these will suppress the warning. But they serve different purposes:
git config pull.rebase false # merge (the default strategy)
This keeps the default behaviour and suppresses the warning.
git config pull.rebase true # rebase
This actually commits on top of the remote branch, maintaining a single branch both locally and remotely (unlike the default behaviour where two different branches are involved - one on local and the other on remote - and, to combine the two, a merge is performed).
git config pull.ff only # fast-forward only
This only performs the pull if the local branch can be fast-forwarded. If not, it simply aborts with an error message (and does not create any commits).
Update 1:
If you have Git 2.29 or above, you can now set pull.ff
to false
, true
or only
to get rid of the warning.
git config pull.ff true
true
- This is the default behaviour. Pull is fast-forwarded if possible, otherwise it's merged.
git config pull.ff false
false
- Pull is never fast-forwarded, and a merge is always created.
git config pull.ff only
only
- Pull is fast-forwarded if possible, otherwise operation is aborted with an error message.
Update 2:
There was a bug in this newly implemented feature until version 2.35
where Git would show this warning even if the user passed one of the three flags with the git pull
command. This has now been fixed, consider updating your Git to version 2.36
or above.
Notes:
Read this very well written answer by torek to get a much clearer picture on what actually happens behind the scene and to understand which option is the most appropriate one for you (along with some interesting insights on the history involved on the topic).
You may want to keep an eye on VonC's answer here for updates on changes made to this feature in future updates.