git rebase is problematic (from a version control system user point of view) because it rewrites history. We all knew that.
But did you know that git pull --rebase, commonly used before a git push, can also be harmful, destroy history, and surprise users in a negative way?
10:08⎜<Beuc:#fusionforge> Lo-lan-do, we must have committed at the same time :) First time I rebase and my commit disappear ;)
10:11⎜«Lo-lan-do:#fusionforge» So who won?
10:11⎜«Lo-lan-do:#fusionforge» Aha, I did :-)
This does fit git’s model of managing patches and tracking content, but is just irresponsible for a version control system. (Also, imagine incensed contributors whose commits just vanish.) So, danger, beware of using git rebasing when you use git as distributed version control system!
In a related way: merge commits are good. Especially when merging between, into or from feature branches. (A friend had his .gitconfig set up to default to rebasing… ugh.) So there should have been one place where you used rebase: to avoid merge commits when people work on the same repository at the same time (but, ideally, on different files). Those were mostly annoying. But, as you can see above, the alternatives are even worse…