I suppose just the usual 'rebase vs. merge' - i.e. if there are conflicts to resolve they will be dealt with commit-by-commit in the usual way when rebasing, whereas without the option set they will be dealt with all at once 'merge-style'. I happen to think that's a feature, but I know some don't like it.
I think there's less argument in favour of merge than usual with pulls though - since it's much less like a semantic merge to begin with for git-merging to preserve a history of.
I'm certainly not aware of any objective downside/gotcha/'oh but it doesn't work when...', no.
Because git was written primarily for the Linux kernel and the defaults reflect that. The workflow of the Linux kernel is completely different from what most people outside of it do with git. "git pull" is used for opposite purposes in both worlds.
I think it's the usually public vs private branch issue.
If you're merging a public branch with another public branch, then if you a rebase, rather than a merge commit, then you mess up the history for anyone has pulled that branch.
I think there's less argument in favour of merge than usual with pulls though - since it's much less like a semantic merge to begin with for git-merging to preserve a history of.
I'm certainly not aware of any objective downside/gotcha/'oh but it doesn't work when...', no.
The docs only add that you might further want to set it to `interactive` or `merges` rather than `true`, for the effect of rebasing with those options: https://git-scm.com/docs/git-config#Documentation/git-config...