what are the pull.rebase false & pull.ff true differences?

is there any difference in using

git config pull.rebase false     # merge (the default strategy)

and

git config pull.ff true

both commands fast-forwards if possible, and if it's not merge.

Which config should I use?

Solution

While both these settings act on how git pull should behave when git, during a git pull, has to reconcile changes in your local branch with upstream changes, they don't turn the same knob.

pull.ff can be set to false | true | only.
It matches the cli options : --no-ff | --ff | --ff-only, and if any of these options is passed on the command line, the config setting is overlooked.

If set to only, git pull will refuse to do anything if the remote branch is not straight ahead of your local branch, so the pull.rebase setting will never kick in.

pull.rebase can be set to false | true | merges | interactive.
It matches the cli option --rebase[=false|true|merges|interactive], and again: if this option is passed on the command line, the config setting is overlooked.

If it is set to something that says "use rebase to combine the changes" (e.g: true|interactive|merges), then a setting stating --ff or --no-ff has no effect -- there won't be a merge anyway.

what should I use ?

This question depends on context. For example :

if your work has a workflow which favors one action specifically, set the defaults to that action
if you are used to a specific sequence of actions, set the defaults to your usage

Instead of answering your question, I will describe how I work :

I personally don't like using git pull, because you get in one go "get the changes you don't know of from the central repo, and merge them with your work", without a chance to review the changes between the two steps.

I generally run :

git fetch
git log --graph --oneline origin/master my/branch (e.g : inspect the state of the remote branch I'm interested in)
run either git rebase origin/master or git merge origin/master (we happen to have a workflow which favors rebase, but anyways : I already have an idea of how complicated that action is going to be)

The difference with git pull is that at step 3, I can do :

merge or rebase an intermediate commit of the remote branch , or an intermediate commit of my own branch,
cherry-pick a specific commit to see what mess it would introduce,
edit my branch before rebasing/merging (one common case: drop that commit which does almost the same thing as the bugfix added on master)
...

I have also set an alias for pull --ff-only, since that one is "harmless" (e.g: you know git will not mess up your code if you run it, it will either do the trivial thing or stop and say "this is not a fast-forward"), and use it to update branches which are not mine.