4 ms·
Are there any downsides to doing this? Why isn't it on by default?
by lambic 5y ago
Are there any downsides to doing this? Why isn't it on by default?
- OJFord 5y agoI 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. 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.txt-pullrebase https://git-scm.com/docs/git-config#Documentation/git-config...
- formerly_proven 5y ago> Why isn't it on by default? 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.
- heurisko 5y agoI 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. For private branches that isn't an issue.