712

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?

Mateen Ulhaq
  • 21,459
  • 16
  • 82
  • 123
Davide Casiraghi
  • 9,996
  • 7
  • 26
  • 48
  • 38
    File a bug report that the warning is confusing. One option should be "recommended" and the warning should only show on request and not just because a version change happened. Lot's of automatic scripts might break now with this unexpected behaviour. – Wolfgang Fahl Jul 17 '20 at 09:07
  • 1
    @WolfgangFahl, the warning shouldn't affect any scripts as it continues to retain the default behaviour until explicitly changed. It shouldn't cause the pull to return a non-zero exit code (given it's a warning, not an error). A few CI/CD scripts that I have deployed accross various servers continue to work with the success rate unaffected. – Qumber Jul 18 '20 at 23:03
  • 1
    @Qumber - thanks for the comment. Crontab entries will e.g. start sending e-mail if output appears that wasn't there or could be filtered with a simple grep. Unexpected output can have all kinds of side effects. – Wolfgang Fahl Jul 20 '20 at 15:55
  • 1
    @WolfgangFahl, Every pull usually has some different output. So, any script that depends solely on that is probably badly written. Also, one should not upgrade a production environment without extensive testing. I prefer to not upgrade prod at all. Instead, I create a new instance with latest everything, host my apps there, test everything out, and then make it production. – Qumber Oct 14 '20 at 06:03
  • I got this message and weirdly enough it seems that it was caused by VS Code. When I entered `git push` in the terminal, my code was pushed without a problem. – MikhailRatner Jan 31 '22 at 22:13

12 Answers12

720

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.

Qumber
  • 9,024
  • 4
  • 17
  • 29
  • 282
    I appreciate the time and effort you put into your answer, but frankly this is still completely incomprehensible to me. – Jared Nedzel Aug 21 '20 at 16:52
  • 6
    As [commented on here](https://stackoverflow.com/questions/62653114/how-to-deal-with-this-git-warning-pulling-without-specifying-how-to-reconcile/62653694#comment111756400_62653694), the warning is not affected by whether or not the branch is *actually* diverging. The initial "Your branch is probably diverging." may be misleading. – Joe Sep 02 '20 at 08:32
  • @Joe, true. Removed. – Qumber Sep 02 '20 at 08:47
  • 6
    I have to say, the three options in the message did *not* work for me to supress the message. However the answer here (`git config --global pull.ff only`) _did_. – DiskJunky Sep 09 '20 at 08:38
  • None of these options are great. `pull.ff true` is much more convenient than `pull.ff only` - it fast-forwards when it can, and merges when it can't, which produces less redundant merge commits than `pull.rebase false`. Is there another way to suppress the message while maintaining the `pull.ff true` behaviour? – stwr667 Sep 17 '20 at 08:21
  • @DiskJunky pay close attention to the next sentence after the 3 options: "You can replace `git config` with `git config --global` to set a default preference for all repositories." – stwr667 Sep 17 '20 at 08:22
  • I believe `pull.rebase false` is the default behaviour. Also `--pull.ff` works out of the box if you don't change it. Setting `pull.rebase false` will preserve the default behaviour where pull is fast-forwarded if possible, and merged when not. See [this](https://git-scm.com/docs/git-config#Documentation/git-config.txt-pullff) & [this](https://git-scm.com/docs/git-pull#Documentation/git-pull.txt---ff) – Qumber Sep 18 '20 at 07:02
  • 1
    Aha! Thanks @Qumber. I had already tried `pull.rebase false`, but it wasn't working as described. It was **always** creating a merge commit, and *never* fast-forwarding. The root cause was that I had the `merge.ff false` setting. After clearing that setting, it fast-forwards when it should. Docs [here](https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---ff) (almost identical to the [git pull](https://git-scm.com/docs/git-pull#Documentation/git-pull.txt---ff) docs) – stwr667 Sep 21 '20 at 03:14
  • Sweet. These `pull` and `merge` configs do tend to override each other at places. – Qumber Sep 21 '20 at 05:56
  • 3
    You have included the Git 2.29 option I mentioned below, good point. Upvoted. – VonC Oct 07 '20 at 07:21
  • 1
    I had to explicitly do `git config pull.ff true` for it to take. – skube Nov 18 '20 at 11:53
  • Worth to mention that while pull.rebase true is amazing option, you won't be able to pull if you have unstashed changes. git pull error: cannot pull with rebase: You have unstaged changes. error: additionally, your index contains uncommitted changes. error: please commit or stash them. etc. – Kamil Dziedzic Jan 22 '21 at 20:03
  • @KamilDziedzic That's because Git does not let you pull with rebase if your index is not clean. One option is to autostash your changes while rebasing - https://stackoverflow.com/a/43262939/10625611 – Qumber Jan 23 '21 at 05:59
  • 5
    Thanks for you answer. Helped a lot. I am working only with feature branches. On my develop there are no local changes. Therefore the default will do pretty well for me. But if I used pull.ff and have a conflict, how would I get that problem and what would I do if ff is not possible? – CanO Feb 01 '21 at 17:45
  • 2
    This is a really good explanation. I've actually run into this unexpected behavior when pulling before. For me, it happened when I used `git pull origin main` to update the main branch while I was still on a feature branch locally (I forgot to checkout to the main branch locally first). It ended up pulling the remote main changes and also merging them into my feature branch. ff seems like a safer strategy. – Matt Welke Mar 02 '21 at 16:59
  • What does "fast-forward" mean here? – Victor Apr 27 '21 at 07:06
  • @Victor Checkout [this answer](https://stackoverflow.com/a/29673993/10625611). – Qumber Apr 27 '21 at 09:14
  • As simple answer has been overcomplicated to confuse you more lol – arled May 13 '21 at 13:23
  • Does anything need to be done when say, you set it to fastforward only, but then a merge is required on a pull? – Chucky Jun 24 '21 at 11:40
  • 1
    @Chucky, you can do a `git pull --merge` if you want to pull using merge. Or `git pull --rebase` to pull using rebase. – Qumber Jun 24 '21 at 16:02
  • Which option was the default behavior in older versions of git from before this warning started showing? I am accustomed to how git pull operated in the past and would like to keep it the same if possible. pull.rebase false mentions that it is the default behavior currently but not whether it was also the default behavior in the past. Was this also the default behavior in prior versions? – FoamyGuy Sep 24 '21 at 15:31
  • 1
    @FoamyGuy, the default strategy has been `merge` (`pull.rebase false`) since _version 1.x_. And continues to be the same. [This doc](https://git-scm.com/docs/git-pull/2.1.4) for _version 2.1.4_ (released 2014) explains the behaviour `"...git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch."`. – Qumber Sep 25 '21 at 09:48
  • This comment is helpful, the warning message says default is `pull.rebase false` but at least in my experience so far, the default strategy has been `pull.ff only` – Pztar Nov 30 '21 at 17:37
  • Time to go back to TFS. git is way too complicated for my enterprise needs. – Heckflosse_230 Apr 15 '22 at 22:21
  • Perhaps this would be clearer if it was explained somewhere what a divergent branch even is. If I add a build pipeline file in Azure, and change a line of text in an unrelated area in my checked out repo I get the `divergent branches` error, but it seems to me that that situation is not even a file conflict. So what is the actual problem? – Neutrino May 08 '22 at 19:08
154

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

Joe
  • 26,561
  • 11
  • 64
  • 84
  • 47
    This is actually the most correct answer, because it explains why people (like me) are suddenly seeing this warning after nearly a decade of using git. However,it would be useful if some guidance were given on the options offered. for example, pointing out that setting pull.ff to "only" doesn't prevent you doing a "pull --rebase" to override it. – kdopen Jun 30 '20 at 12:01
  • What's the difference between `pull.rebase = true` and `branch.autoSetupRebase = always` ? – tekumara Jul 19 '20 at 08:56
  • 2
    @tekumara see https://stackoverflow.com/a/15935584/733345 – Joe Jul 19 '20 at 10:18
  • 6
    "when there are changes in your branch but not present in the remote branch." Then it seems to me that git should only throw this warning *if that is the case.* If I'm pulling my mainline (and the mainline is used properly) I shouldn't need to worry about that. – Keith Tyler Jul 31 '20 at 21:13
  • @KeithTyler that's reasonable, but, as this warning is only logged and doesn't cause the command to fail, that could mean you only see it *after* your history has been changed in a way you don't expect. The intent is for you make a decision upfront. – Joe Aug 01 '20 at 11:03
  • 9
    @Joe I like your answer, and think it's the _right_ answer, but you see this regardless of whether git has actually _done_ anything. I feel that the right time to issue this warning is if git has to _do_ something, then should fail with this message. Not just spam users with this message upfront. Yet another thing that contributes to my love/hate relationship with git. – Jon V Aug 06 '20 at 13:49
  • 2
    Joe, thanks for your answer, it helps a lot. I'm not sure I understand what the ff-only flag is about. If `git pull` fails because ff-only is enabled, then what? At that point one must do a merge or rebase by hand in order to make any progress. So if the goal is to avoid messy dependency graphs, this doesn't change anything -- one way or another, automatically or by hand, your dependency graph will end up a mess. I suppose that if you have to do it by hand, you have more control over it. However I'm guessing that usually people won't know how to avoid a mess any more than the Git itself does. – Robert Dodier Oct 28 '20 at 17:02
69

Run this:

git config pull.ff only

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

Snowcrash
  • 73,844
  • 72
  • 228
  • 347
35

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.

VS 2019 - Git

chri3g91
  • 824
  • 11
  • 13
28

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.

Asclepius
  • 49,954
  • 14
  • 144
  • 128
sensorario
  • 18,131
  • 26
  • 91
  • 148
21

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.

VonC
  • 1,129,465
  • 480
  • 4,036
  • 4,755
  • 1
    In my case, I'm unable to do ff with git pull after setting git config to ff only. what should I do now? git version - 2.33.1. – y_159 Oct 18 '21 at 08:34
  • @y_159 It would be best to ask a new question detailing your situation in details, for me (and others) to suggests options/solutions. – VonC Oct 18 '21 at 08:43
  • 1
    Git 2.34 is still broken. It refuses to pull a remote branch which is an ancestor of the current branch head. – Ark-kun Nov 24 '21 at 03:54
  • @Ark-kun But if the remote branch is an ancestor (meaning included in) of your current local branch, there would be nothing to pull, would it? – VonC Nov 24 '21 at 06:53
  • >there would be nothing to pull, would it? - Yes. But 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. Waiting for release... – Ark-kun Nov 26 '21 at 07:48
  • @Ark-kun Interesting. Do you have an issue or pull-request reference for that fix? – VonC Nov 26 '21 at 07:49
  • https://lore.kernel.org/git/CADL96rvRX2R_4Wm23tz88hDUztcpK531RU+Ops2UVoiOW0bCHw@mail.gmail.com/ https://github.com/git/git/commit/ea1954af771253660cd84dc73b8f2832327c9c02#diff-0e7db391c63d3bfd3f16472a3137dadf0281a91ae0de4c6eb95cb984230b9335 – Ark-kun Nov 28 '21 at 10:09
  • @Ark-kun Thank you for this feedback. I have included your comment and the relevant references in the answer for more visibility. – VonC Nov 28 '21 at 11:46
1

This issue is fixed in 2.34.1 update your Git version.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Jo Lewis
  • 11
  • 1
  • 1
    2.35 will be more robust. See [my answer below](https://stackoverflow.com/a/64163084/6309). It will be released next week. – VonC Jan 19 '22 at 18:26
0

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.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Yamen Ashraf
  • 2,201
  • 2
  • 18
  • 23
0

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

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
RAIIIIIN
  • 1
  • 2
  • It is still broken, and is being fixed for Git 2.34.2 or 2.35. See the [end of my answer](https://stackoverflow.com/a/64163084/6309). – VonC Nov 30 '21 at 13:44
  • It seems that you have actually worked on the subject more than I have. Ahah. However, I no longer have this concern of "Pulling without specifying how to reconcile divergent branches is discouraged." since version 2.34.1 of Git. – RAIIIIIN Dec 02 '21 at 08:20
0

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

Archit Puri
  • 358
  • 2
  • 10
-1

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

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
hello world
  • 1
-1

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

Manas Kumar Maharana
  • 653
  • 7
  • 8