'How can I deal with this Git warning? "Pulling without specifying how to reconcile divergent branches is discouraged"
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 should I do?
Solution 1:[1]
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:
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.
Note: You may want to keep an eye on VonC's answer here for updates on changes made to this feature in future updates.
Solution 2:[2]
This is a new warning added in Git 2.27:
* "git pull" issues a warning message until the pull.rebase
configuration variable is explicitly given, which some existing
users may find annoying---those who prefer not to rebase need to
set the variable to false to squelch the warning.
To remove the warning, set one of the suggested values to your preferred default behaviour for git pull
if you don't specify behaviour on the command line (using --ff
, --no-ff
, --ff-only
, --rebase
). In all cases, git
will attempt a fast-forward (What is git fast-forwarding?) merge if possible. The settings control what happens when there are changes in your branch but not present in the remote branch.
git config pull.rebase false # merge (the default strategy)
This is the existing default behaviour; set this for no warning, and no change in behaviour; git
will merge the remote branch into your local one.
git config pull.rebase true # rebase
Here, git
will attempt to rebase your changes on top of the remote branch. See When should I use git pull --rebase? for more detail on why you might want that.
git config pull.ff only # fast-forward only
If a fast-forward merge is not possible, git
will refuse to proceed. As Difference between git pull --rebase and git pull --ff-only quotes:
Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward
Solution 3:[3]
Run this:
git config pull.ff only
and congratulate yourself that you can get on with your work.
Solution 4:[4]
If one is using Git with Visual Studio (2019 or 2022) and started experiencing this issue, then you can define this option from the Git Tab -> Settings.
Rebase local branch when pulling
Set as false if you want the branch to 'merge' changes and True if you want to 'rebase' the changes.
Solution 5:[5]
git config pull.ff only
or equivalently git pull --ff-only
is the safest one. The reason is that a rebase can overwrite the history and may cause the loss of commits if another developer has force-pushed to the same branch.
But all of them are valid.
Solution 6:[6]
Note: Earlier we taught "git pull
"(man) to warn when the user does not say the histories need to be merged, rebased or accepts only fast-forwarding, but the warning triggered for those who have set the pull.ff
configuration variable.
This is no longer the case (meaning: no more warning) with Git 2.29 (Q4 2020).
See commit 54200ce (24 Sep 2020) by Alex Henrie (alexhenrie
).
(Merged by Junio C Hamano -- gitster
-- in commit 299deea, 29 Sep 2020)
pull
: don't warn ifpull.ff
has been setSigned-off-by: Alex Henrie
A user who understands enough to set
pull.ff
does not need additional instructions.
Before Git 2.31 (Q1 2021), when a user does not tell "git pull
"(man) to use rebase or merge, the command gives a loud message telling a user to choose between rebase or merge but creates a merge anyway, forcing users who would want to rebase to redo the operation.
Fix an early part of this problem by tightening the condition to give the message--- there is no reason to stop or force the user to choose between rebase or merge if the history fast-forwards.
See commit 7539fdc, commit b044db9 (14 Dec 2020) by Junio C Hamano (gitster
).
See commit c525de3, commit 278f4be, commit 77a7ec6 (12 Dec 2020) by Felipe Contreras (felipec
).
(Merged by Junio C Hamano -- gitster
-- in commit d3fa84d, 06 Jan 2021)
pull
: display default warning only when non-ffSuggestions-by: Junio C Hamano
Signed-off-by: Felipe Contreras
There's no need to display the annoying warning on every pull... only the ones that are not fast-forward.
The current warning tests still pass, but not because of the arguments or the configuration, but because they are all fast-forward.
We need to test non-fast-forward situations now.
The warning changes with With 2.34 (Q4 2021): "git pull
"(man) had various corner cases that were not well thought out around its --rebase
backend, e.g. "git pull --ff-only
"(man) did not stop but went ahead and rebased when the history on other side is not a descendant of our history.
See also below: Git 2.34 does not yet fix everything.
See commit 6f843a3, commit 359ff69, commit 031e2f7, commit adc27d6, commit e4dc25e (22 Jul 2021), and commit 1d25e5b, commit be19c5c (21 Jul 2021) by Elijah Newren (newren
).
See commit 3d5fc24 (21 Jul 2021) by Alex Henrie (alexhenrie
).
(Merged by Junio C Hamano -- gitster
-- in commit 7d0daf3, 30 Aug 2021)
pull
: abort by default when fast-forwarding is not possibleInitial-patch-by: Alex Henrie
Signed-off-by: Elijah Newren
We have for some time shown a long warning when the user does not specify how to reconcile divergent branches with
git pull
.
Make it an error now.
git pull
now includes in its man page:
Incorporates changes from a remote repository into the current branch.
- If the current branch is behind the remote, then by default it will fast-forward the current branch to match the remote.
- If the current branch and the remote have diverged, the user needs to specify how to reconcile the divergent branches with
--no-ff
,--ff
, or--rebase
(or the corresponding configuration options inpull.ff
orpull.rebase
).More precisely,
git pull
runsgit fetch
with the given parameters and then depending on configuration options or command line flags, will call eithergit merge
orgit rebase
to reconcile diverging branches.
So: instead of seeing (before Git 2.33.1):
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
You will see:
You have divergent branches and need to specify how to reconcile them.
You can do so 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
Meaning, if you don't run one of those commands, you will get a fatal error:
fatal: Need to specify how to reconcile divergent branches.
Update for Git 2.35 (Q1 2022)
Ark Kun reports:
Git 2.34 is still broken. It refuses to pull a remote branch which is an ancestor of the current branch head.
git fails instead of doing nothing.
VSCode has sync feature that does pull and push.
The feature has been broken for months because GIT changed the behavior.Fortunately this issue is finally fixed in GIT master
That was reported/discussed in this Git mailing thread, and a fix is in progress (git commit ea1954a)
Before Git 2.35 (Q1 2022), "git pull
"(man) with any strategy when the other side is behind us should succeed as it is a no-op, but doesn't.
See commit ea1954a (17 Nov 2021) by Erwin Villejo (erwinv
).
(Merged by Junio C Hamano -- gitster
-- in commit 0f2140f, 21 Nov 2021)
pull
: should be noop when already-up-to-dateSigned-off-by: Erwin Villejo
The already-up-to-date pull bug was fixed for
--ff-only
but it did not include the case where--ff
or--ff-only
are not specified.This updates the
--ff-only
fix to include the case where--ff
or--ff-only
are not specified in command line flags or config.
Solution 7:[7]
This issue is fixed in 2.34.1 update your Git version.
Solution 8:[8]
The safest option is set ff only globally. run:
git config --global pull.ff only
This option will be added to your global .gitconfig
.
[pull]
ff = only
If the fast-forward later is failing, try git pull --no-ff
.
Solution 9:[9]
I don't know if it's related to your problem, but note that there was a problem with the v2.34.0 version of Git. The git pull
command haven't the behavior that is expected.
A message from the release note about the fix coming from Git and the new version from 2021-11-24:
"git pull" with any strategy when the other side is behind us should succeed because it's a no-op, but doesn't".
Solution 10:[10]
For me it, once I setup the config, still I was unable to merge. It was giving fatal: Not possible to fast-forward, aborting
None of the above solutions worked so I used merging with develop. merge origin/develop
Solution 11:[11]
Make sure the branch you're currently in exists in the remote repository. If you are working with Atlassian (Bitbucket and Jira) could be that after a pull request your branch got deleted and you forgot to check out to some other branch (i.e. master/develop).
Solution 12:[12]
Lets example you created one branch A from develop branch and during pull from develop to A branch getting this divergent issue. you unable to took update code from develop to ur A branch. so follow this steps to fix this issue
- git checkout develop-branch (this will switch to develop brnach)
- git pull (it will pull all changes to develop)
- git checkout A-feature-branch ( this will switch to your feature branch)
- git merge develop-branch (it will merge all change to your feature branch)
Now, you have updated code from develop to your local branch . Enjoy your coding :)
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow