Hacker News new | ask | show | jobs
by OJFord 1560 days ago
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.

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...