fast forward when using pull and no-ff when merging branch

Note: Git 2.0 (Q2 2014) will introduce with commit b814da8 a config push.ff:

pull.ff:: 

By default, Git does not create an extra merge commit when merging a commit that is a descendant of the current commit. Instead, the tip of the current branch is fast-forwarded.

• When set to false, this variable tells Git to create an extra merge commit in such a case (equivalent to giving the --no-ff option from the command line).
• When set to only, only such fast-forward merges are allowed (equivalent to giving the --ff-only option from the command line).

Initial answer (October 2012)

Try a:

git pull --ff 

It should take precedence on your merge config setting.
It will pass the --ff option to the underlying merge within the git pull command.

Beware of the --no-ff option though, as mentioned in "Understanding the Git Workflow"

With enough flags you can force Git to act the way you think it should instead of the way it wants to. But that’s like using a screwdriver like a hammer; it gets the job done, but it’s done poorly, takes longer, and damages the screwdriver.

Consider how a common Git workflow falls apart.

Create a branch off Master, do work, and merge it back into Master when you’re done 

Most of the time this behaves as you expect because Master changed since you branched. Then one day you merge a feature branch into Master, but Master hasn’t diverged. Instead of creating a merge commit, Git points Master to the latest commit on the feature branch, or “fast forwards.” (Diagram)

Unfortunately, your feature branch contained checkpoint commits, frequent commits that back up your work but captures the code in an unstable state. Now these commits are indistinguishable from Master’s stable commits. You could easily roll back into a disaster.

So you add a new rule: “When you merge in your feature branch, use –no-ff to force a new commit.” This gets the job done, and you move on.

Then one day you discover a critical bug in production, and you need to track down when it was introduced. You run bisect but keep landing on checkpoint commits. You give up and investigate by hand.

You narrow the bug to a single file. You run blame to see how it changed in the last 48 hours. You know it’s impossible, but blame reports the file hasn’t been touched in weeks.
It turns out blame reports changes for the time of the initial commit, not when merged. Your first checkpoint commit modified this file weeks ago, but the change was merged in today.

The no-ff band-aid, broken bisect, and blame mysteries are all symptoms that you’re using a screwdriver as a hammer.

For more, see:

• "With dvcs/git, is a single commit preferred over multiple, small, thematic commits?"
• "git newbie question - Commit style: Commit all changed files at once or one at a time?"