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?

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

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 (https://stackoverflow.com/questions/29673869/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 https://stackoverflow.com/questions/2472254/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 https://stackoverflow.com/questions/25430600/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

Run this:

git config pull.ff only

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

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.

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.

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.

This issue is fixed in 2.34.1 update your Git version.

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.

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

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

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

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

In my case, a file is removed from .gitignore and conflict with my local version. To solve it, I move the file(local) to a temporary place.