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?

Martens

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

@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. – Yetty

@Yetty - 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. – Hotchpotch

@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. – Yetty

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

Like @MikhailRatner, I used git push in the terminal without any issues. If someone faces this problem in the VS Code, I recommend trying this solution. – Pastel

Checkout this answer: stackoverflow.com/questions/71768999/… – Kosey

In my case I resolved it just using: git pull --no-ff – Huddle

The comments here and at stackoverflow.com/questions/71768999/… suggest that git's output simply isn't up to the job of communicating with its users about what the problem is. "File a bug report" might actually be the right answer, if anything good would come of it. Though long, https://mcmap.net/q/14142/-how-to-merge-when-you-get-error-quot-hint-you-have-divergent-branches-and-need-to-specify-how-to-reconcile-them-quot is actually the best explanation. – Dansby

I get the same problem frequently, and have a real problem solving it. I am the only one who has ever cloned the repo, and I am the only one who has ever pushed, and only from one dir. But I always get this error, and the recommended "fix" "git config pull.ff only" gives "fatal: Not possible to fast-forward, aborting." leaving me more confused than before. – Overheat

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.

Yetty

As commented on here, the warning is not affected by whether or not the branch is actually diverging. The initial "Your branch is probably diverging." may be misleading. – Varus

@Joe, true. Removed. – Yetty

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

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? – Silesia

@Windswept 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." – Silesia

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 & this – Yetty

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 (almost identical to the git pull docs) – Silesia

I had to explicitly do git config pull.ff true for it to take. – Robbirobbia

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

@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://mcmap.net/q/14143/-error-cannot-pull-with-rebase-you-have-unstaged-changes – Yetty

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? – Fleshly

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

What does "fast-forward" mean here? – Granger

@Granger Checkout this answer. – Yetty

As simple answer has been overcomplicated to confuse you more lol – Quarrier

Does anything need to be done when say, you set it to fastforward only, but then a merge is required on a pull? – Hackworth

@Chucky, you can do a git pull --merge if you want to pull using merge. Or git pull --rebase to pull using rebase. – Yetty

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? – Confined

@FoamyGuy, the default strategy has been merge (pull.rebase false) since version 1.x. And continues to be the same. This doc 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.". – Yetty

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 – Amand

Time to go back to TFS. git is way too complicated for my enterprise needs. – Anthurium

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? – Journeywork

This works for me: git config pull.ff true – Cicala

Answer 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

Varus

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

What's the difference between pull.rebase = true and branch.autoSetupRebase = always ? – Seclude

@Seclude see https://mcmap.net/q/14146/-how-can-i-pull-all-remote-changes-with-rebase-instead-of-merge – Varus

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

@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. – Varus

@Varus 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. – Ruth

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

This command alone worked for me: git config pull.rebase false – Tiller

Answer 3

git pull origin main --rebase

worked for me!

Bissau

Same here. If you just had a commit on origin but forget to pull before commiting something else locally, but got no conflicts, this one (a simple rebase) will solve it for you. – Unaccountedfor

I agree with stackoverflow.com/users/8991247/caique-c-pereira. – Feeler

I have a lot of conflicts after that :( – Adila

this is the way, you are not modifying the other new commits from remote. And the world doesn't need to know about your local commits so feel free to modify and change its hash. @VitalyZdanevich of course you can have merge conflict, you have to deal with it with or without rebase anyway. What do you expect? – Tereasaterebene

Answer 4

Run this:

git config pull.ff only

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

Goer

fatal: Not possible to fast-forward, aborting. – Fondness

@Fondness Maybe is too late for you but it can be useful to someone else. To solve the fatal: Not possible to fast-forward, aborting warning I used git pull origin <branch> --rebase. I have also noticed I didn't have the upstream set so in the first push I added that (-u) e.g. git push -u origin <branch>. – Tersina

@ViníciusCerqueiraBonifácio I usually get this error, I ended up doing git pull --no-ff. I'll try your suggestion. – Fondness

This doesn't explain what it does, and will only cause more problems down the line, when ff is not possible and the inexperienced user will be at loss on what to do -- additionally, with a non-default behaviour which will be harder to debug. – Hypersonic

git config pull.ff only worked for me; required git pull before I could resume a push. – Pipit

I get the same problem: fatal: Not possible to fast-forward, aborting. This whole thing is a mystery: i am the only one who has ever cloned the repo, and the only one who has ever pushed to it, and only from one dir. What on earth is going on? – Overheat

Answer 5

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.

Rand

This did work for me on Visual Studio Enterprise 2022. – Churchman

Answer 6

It works for me

git config --global pull.ff true

Pneumatograph

This worked for me, while other solutions (event the most upvoted) gave me errors. Thank you. – Cycloid

this is the best answer so far. – Bellows

I get "fatal: Not possible to fast-forward, aborting" – Overheat

try it git pull --no-ff – Pneumatograph

Answer 7

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.

Bravar

Don't do this unless you know what you're doing. You may end up losing your local work! – Hypersonic

@Martino, you are right but this is clearly mentioned in the post that this will discard any local changes and make a fresh carbon copy as the remote.... – Bravar

I got git reset --hard origin/dev fatal: ambiguous argument 'origin/dev': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' – Adila

Answer 8

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.

Except

How would that 'loss of commits' happen, actually? – Arette

"Loss of commits" does not happen. But if there are reverts and re-reverts it may choose the "in" or "out" for that change that you don't want. So it looks like it loses the revert, or the re-revert. Also if you're in the habit of commenting out old code a change may be applied to the commented out copy rather than the copy you want. FF-only doesn't do any of this patching so it's boring and safe. – Judaist

Doesnt work for me. fatal: Not possible to fast-forward, aborting. This is with the simplest possible repository, with only 1 main branch, and 2 people. Its unfortunately two people (Who are not git experts) editing different files at the same time is such a problem for git. – Overheat

Answer 9

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.

Worms

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

@Fondness It would be best to ask a new question detailing your situation in details, for me (and others) to suggests options/solutions. – Worms

Git 2.34 is still broken. It refuses to pull a remote branch which is an ancestor of the current branch head. – Elysian

@Elysian But if the remote branch is an ancestor (meaning included in) of your current local branch, there would be nothing to pull, would it? – Worms

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

@Elysian Interesting. Do you have an issue or pull-request reference for that fix? – Worms

lore.kernel.org/git/… github.com/git/git/commit/… – Elysian

@Elysian Thank you for this feedback. I have included your comment and the relevant references in the answer for more visibility. – Worms

Answer 10

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.

Shabbir

Thanks alot it was bothering me since long, – Kudu

Answer 11

git config pull.rebase false

merge (the default strategy)

Dextrad

Answer 12

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.

Fertilize

Answer 13

The default merging process instead of using rebasing

git config pull.rebase false

then

git pull origin <branch name>

Hosea

Answer 14

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

Intermolecular

Answer 15

In my case I resolved it just using:

git pull --no-ff

Stepper

What will happen exactly if we use this command. It's working for me but don't know how it will work. – Shabbir

What does --no-ff for git merge? The --no-ff flag prevents git merge from executing a "fast-forward" if it detects that your current HEAD is an ancestor of the commit you're trying to merge. – Huddle

Answer 16

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.

Archpriest

did you use any generative AI like chatgpt at all in the writing of any part of this answer? – Horvath

Answer 17

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.

Baggott

Answer 18

This command did the trick

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

Hornback

Answer 19

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

Opaque

Answer 20

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.

Velazquez

Answer 21

This worked in my case:

git rebase origin/my_remote_branch_name

Acosmism

Answer 22

git pull origin --rebase

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

Nobby

Answer 23

This issue is fixed in 2.34.1 update your Git version.

Dramatist

2.35 will be more robust. See my answer below. It will be released next week. – Worms

Answer 24

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

Tamberg

Answer 25

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.

Tithonus

This is essentially an extremely convoluted way of doing a pull. – Hypersonic

Answer 26

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

git pull --tags -f

Miserly

Answer 27

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

Durr

Answer 28

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

Conceptualize

It is still broken, and is being fixed for Git 2.34.2 or 2.35. See the end of my answer. – Worms

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

Answer 29

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

Gladiate

This is what happens if you set the third option but no ff is available. In that case you might be able to solve it with git pull --no-ff – Hypersonic

Answer 30

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.

Trudytrue

Answer 31

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

Credulous

Answer 32

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.

Cordierite

Answer 33

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

Connubial

Answer 34

It's works for me.

git reset --hard origin/<remote_branch_name>

Interlace

This not only doesn't answer the question, but is also DANGEROUS because you may lose your work. – Hypersonic