Pull creates unnecessary merge commit

[Vincent Falconi]

Seemingly out of nowhere, SourceTree (1.6.23, Win7 x64) has started creating a new merge commit whenever I pull changes from remote (GitHub), then telling me I am one commit ahead and can push that change back up to origin. When all I did was sync up with the remote branch. If I right click on the last commit from the remote, and choose "Reset current branch to this commit," everything goes back to what I expect. The only box checked on the Pull dialog is "Commit merged changes immediately." I've tried experimenting with unchecking that, or also checking "Create new commit even if fast-forward is possible," or unchecking "Commit...immediately" and only checking "Create new commit..." and that doesn't fix it either.

I've tried to figure this out by removing any possible issues in `.git/config` (no help), as well as `.git/sourcetreeconfig` (no help)–this is when I realized it happens no matter what repo I'm working in.

My coworker has the same setup as me (same OS, same SourceTree version, same repo, same remote), and he does not have this issue.

Having to reset the branch every time I pull doesn't seem like that big of a hassle, but it starts to eat up my time–especially when things run slowly.

Have I changed a setting in SourceTree and just not realized it? 

[pFreak]

Check that Sourcetree is using your System Git and then check you ".gitconfig".

Fastforward is probably disabled:

ff=false

change it to ff=true

[sschilz]

We are also experiencing this with one of our developers here is having this same behavior, it's making our commit history an unnecessary mess!  Any suggestions on fixing it?

[Vincent Falconi]

Full output: git -c diff.mnemonicprefix=false -c core.quotepath=false fetch origin From github.com:vfalconi/test_repo 571c9f2..4f288e6 master -> origin/master git -c diff.mnemonicprefix=false -c core.quotepath=false pull origin master From github.com:vfalconi/test_repo * branch master -> FETCH_HEAD Merge made by the 'recursive' strategy. README.md | 2 ++ 1 file changed, 2 insertions(+) git -c diff.mnemonicprefix=false -c core.quotepath=false submodule update --init --recursive Completed successfully.

[Seth]

Yeah, that's definitely the same behavior as "Create new commit...". When you hit OK on that Pull dialog, check the "Show full output" box in the progress window, and post that output (redact as necessary).

[Vincent Falconi]

Sure, don't know why I didn't think to include some screen shots in my post. And yeah, I _thought_ "Create new commit..." would result in this behavior, which is why I'm so confused as to why this is happening. (I checked the default Git settings, too, to make sure this wasn't set there for some reason: https://vincefalconi.com/sourcetree-problem/sourcetree-global-git.png) I created a new repo to demonstrate the problem. This is my graph after making a few changes locally: https://vincefalconi.com/sourcetree-problem/sourcetree-local-commits.png This is my pull dialog: https://vincefalconi.com/sourcetree-problem/sourcetree-pull-dialog.png This is my graph after the pull completes: https://vincefalconi.com/sourcetree-problem/sourcetree-graph-after-pull.png This is my graph after I click "Rest current branch...", which shows what I expect the graph to look like: https://vincefalconi.com/sourcetree-problem/sourcetree-graph-after-reset.png

[Seth]

Firstly, you definitely do NOT want to check "Create new commit even if fast-forward is possible". That will result in the behavior you are describing. I'd be curious to see screenshots of your graph before and after a Pull.