How can I deal with this Git warning? "Pulling without specifying how to reconcile divergent branches is discouraged"

Question

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?

Answer 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 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 option for you.

• You may want to keep an eye on VonC's answer here for updates on changes made to this feature in future updates.

Answer 2

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.

Answer 3

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

Answer 4

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 if pull.ff has been set

^{Signed-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-ff

^{Suggestions-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 possible

^{Initial-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 in pull.ff or pull.rebase).

More precisely, git pull runs git fetch with the given parameters and then depending on configuration options or command line flags, will call either git merge or git 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-date

^{Signed-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.

---

With Git 2.41 (Q2 2023), after "git pull"^(man) that is configured with pull.rebase=false merge.ff=only fails due to our end having our own development, give advice messages to get out of the "Not possible to fast-forward" state.

See commit 765071a (07 Mar 2023) by Felipe Contreras (felipec).
^{(Merged by Junio C Hamano -- gitster -- in commit 9de14c7, 19 Mar 2023)}

advice: add diverging advice for novices

^{Signed-off-by: Felipe Contreras
Acked-by: Taylor Blau}

The user might not necessarily know why ff only was configured, maybe an admin did it, or the installer (Git for Windows), or perhaps they just followed some online advice.

This can happen not only on pull.ff=only, but merge.ff=only too.

Even worse if the user has configured pull.rebase=false and merge.ff=only, because in those cases a diverging merge will constantly keep failing.
There's no trivial way to get out of this other than git merge --no-ff^(man).

Let's not assume our users are experts in git who completely understand all their configurations.

git config now includes in its man page:

diverging

Advice shown when a fast-forward is not possible.

So, instead of just seeing:

Not possible to fast-forward, aborting.

You will see:

Diverging branches can't be fast-forwarded, you need to either:

  git merge --no-ff

or:

  git rebase

Not possible to fast-forward, aborting.

Answer 5

Run this:

git config pull.ff only

and congratulate yourself that you can get on with your work.

Answer 6

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.

Answer 7

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).

Answer 8

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".

Git v2.34.1 Release Notes

Answer 9

This issue is fixed in 2.34.1 update your Git version.

Answer 10

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.

Answer 11

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

Answer 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

1. git checkout develop-branch (this will switch to develop brnach)
2. git pull (it will pull all changes to develop)
3. git checkout A-feature-branch ( this will switch to your feature branch)
4. 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 :)

Answer 13

It works for me

git config --global pull.ff true

Answer 14

In my case, I was pulling from a different branch when I intended to just get the latest update of the branch I want. I change back the branch, and it's back to normal.

Answer 15

git config pull.rebase false

merge (the default strategy)

Answer 16

This worked in my case:

git rebase origin/my_remote_branch_name

Answer 17

There are already few good answers mentioned above but if you find it confusing you can try this out (warning: if you have local changes the following command will wipe the changes):

git reset --hard origin/<remote_branch_name>

Example: if your branch name is master

git reset --hard origin/master

This command will discard any of your local branch changes and make your local branch exactly same as your remote brach. In another word, it makes your local branch a carbon copy of your remote branch.

Answer 18

git pull origin main --rebase

worked for me!

Answer 19

Wow lots of good answers here. But I want to answer from a route cause perspective...

Not easy to determine the OP Route Cause each person could be different. Fixing issues is great but preventing them in the first place is even better. although I respect the answer above because their knowledge is far greater than mine.

Here is the Cause of my Issue same error as above:

1. Doing a Commit and Push Pull from my Dev Branch to my remote Dev Branch (using VS Code);
2. Then a PR to my Team Branch.
3. then within github I merged my Team Branch into my Dev Branch (higher) to bring Dev up to level with other teams to ensure we all align.
4. Next morning I do a new commit, but when I go to Push/Pull in VS Oce on my local I get the error.

What I should have done is after my merge in remote, I should Pull or Fetch Remote into my local before making further changes then I would not have gotten the error.

So my daily routine should change, when I merge Team into Dev on my remote I must also pull it to Local straight away

I also had another compounding factor that my new commit clashed with what was merged into my Dev branch, so I received different error for that telling me to remove or stash my changes before I Pull.

So to round this out doing things in the right order might have prevented the error in the first place. (might have).

Answer 20

This means that your local master and remote master have diverged, meaning they both have contributions that cannot be simply fast-forwared. In order to keep your local commits you can follow these steps:

1. git switch -C feature_branch (from master, create local branch with your local commits)
2. git switch master
3. git reset --hard origin/master (lose all local changes, and become same as origin/master)
4. git switch feature_branch
5. git merge master (add remote changes to your local)
6. git push
7. Make a pull request for master.

Answer 21

I kept getting errors with --ff-only, so I just created a new branch that I synchronized with the remote one:

Jump on another branch:

git checkout -b other-branch

Change its name so it doesn't bother you:

git branch -m myBranch broken-myBranch

Checkout the remote branch you wish to sync:

git checkout origin/myBranch

Create a local branch for it:

git checkout -b myBranch

Attach the remote branch to yours:

--set-upstream-to=origin/myBranch myBranch

Answer 22

It's works for me.

git reset --hard origin/<remote_branch_name>

Answer 23

The issue will be resolved with below command

git config --global pull.ff true run this command in your project directory terminal.

This is a ideal solution for this through Desktop, but in the mean time. For those unfamiliar with using the Command Line Interface (CLI).

From GitHub Desktop, you can press Ctrl + ` (Also available from the "Repository" main menu as "Open in [Your set terminal]"). This should open up a CLI.

From SourceTree -> Actions -> Open in Terminal. This will open Terminal with your project directory.

In Terminal just type: git config --global pull.ff true (or any of the other options specified in the error hints).

Now when you attempt to pull it will use that configuration and allow you to continue.

I suggested pull.ff true simply because it attempts to fast forward your branch to be up to date with your remote before applying your local commits and if not it will perform a merge from the remote to your local branch. Read docs here.

Typically when you pull a branch, add commits, and push. It is in the order assuming your local is up to date with remote. By merging when fast forwarding is not possible, you will see a merge commit informing you of how it was handled. (The other options are to rebase or always merge, many new users find rebase to be less intuitive, but really accomplishes the same thing)

I added the --global flag so that your choice will apply to all your repos and you won't see this error message again. Simply omit this if you want a different behaviour for each repository.

Answer 24

In my case I just simply did this by :

git pull --rebase

I was able to get all the remote changes on my local branch.

Thanks.

Answer 25

In my case my issues was tags, and below is the fix:

git pull --tags -f

Answer 26

git pull origin --rebase

worked for me! I was trying to get manually uploaded files to project folder.

Answer 27

Solving this issue is easier with some a tool having ui for git. I use IntelliJ for this. Here are the steps you need to follow:-

1. Checkout to the branch in which you want to merge your code (say master).
2. Take latest pull in master (git pull origin master).
3. Checkout to you branch (say test).
4. Right click in the editor -> go to Git -> Merge
5. Select master branch in the popup. Click on merge
6. Resolve conflicts (if any).
7. Run "git pull origin test" in your test branch
8. Run "git push origin test" in your test branch

Congratulations!!! You fixed the issue.

Answer 28

In my case I resolved it just using:

git pull --no-ff

Answer 29

This command did the trick

git pull --rebase
Successfully rebased and updated refs/heads/<branch>

Answer 30

I didn't have changes in my local branch.

I only wanted to pull the latest changes from the remote server into my local branch.

So I deleted the 'unmerged' local branch (in the following example: troublesome_branch) and then switch to the remote version of it:

git checkout another_branch
git branch -D troublesome_branch
git checkout troublesome_branch

Answer 31

Whenever you perform a git pull operation from the remote host, git will essentially merge remote into your local branch.

The error indicates that your local branch has diverged from the upstream remote branch. For example, this may happen whenever you rebase the remote branch (e.g. from GitHub UI), and at the same time you have attempted to push new changes from your local branch without first pulling the changes from the remote host.

---

The following command should help you resolve the error:

git pull origin <branch-name> --rebase

and you should now be able to git push from local to remote

Answer 32

Try this answer-

You can use 'git config pull.rebase false' command to switch back to default merging strategy instead of using rebasing

git config pull.rebase false

Then use your pull command

git pull origin <Your branch name>

Answer from...

https://www.cyberithub.com/solved-fatal-need-to-specify-how-to-reconcile-divergent-branches/#:~:text=Solution%201%3A%20Switch%20to%20Merge%20Strategy&text=You%20can%20use%20git%20config,instead%20of%20using%20rebasing%20strategy.&text=After%20switching%20back%20to%20default,the%20changes%20from%20main%20branch.

Answer 33

These are hints from Git. It's suggesting that you configure your preferred behavir for the git pull command. Here's how you can configure it:

Merge (Default Behavir): If you want to perform a merge when pulling changs, you can configure Git like this:

git config pull.rebase false

This will make git pull perform a merge by default.

Rebase: If you prefer to rebase your changes on top of the incoming changes, you can configure Git like this:

git config pull.rebase true

Rebase moves your local commits on top of the incoming commits from the remote branch, creating a linear history.

Fast-Forward Only: If you want to ensure that your branch only fast-forwards (i.e., updates without creating merge or rebase commits), you can configure Git like this:

git config pull.ff only

This will allow git pull to fast-forward your branch if possible; otherwise, it will reject the pull if it would result in a merge or rebase.

Answer 34

The default merging process instead of using rebasing

git config pull.rebase false

then

git pull origin <branch name>