I can't comment on the motivations of the maintainers, but in my experience normal merges can handle more conflicts cases smoothly than rebase. Rebase is also controversial because technically it's rewriting history. I think for the special case of pulling from remote, though, that the tradeoffs are often worth it, but nevertheless, merge is the safer default.
REMOTE history is absolutely sacrosanct (A remote being any repository that someone is going to pull from), but you can do whatever you like with your local repository, so long as you only push from it.
OK, but I believe remote repo is there only to be pushed to, so then is there any example of benefit of pull without --rebase if the pull is anyway only done locally?
Says " If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble." but not how that can happen at all, provided you always "pull --rebase" and then "push", and if that can happen at all, then what to do.
Sacrosanct? No. But still useful. With a real merge, you get a special commit that summarizes what had to be done to complete the merge. That can come in handy, especially with the sort of bugs that creep in during merges. Rebase will actually change your original commit, which obscures the original intent of the commit and hides the merge. In those cases I'd rather have a slightly messier history but more information about what really happened.
reply