I must say I disagree with John a lot about git rebase.

git-rebase is the most nice feature I've ever seen float around in a SCM, and is part of the things I love in git. I mean, I do not disagree with the fact that it cannot be used in every single case. It is indeed meant to be used in private topic branches. git-rebase is meant to be used in a workflow where you have a topic branch (meaning some non releaseable nor push-able work) and that you still want to keep up with others work.

With other SCM's, you have to update your working repository, wich in many cases generates nasty conflicts, hard to deal with. Especially in svn e.g.. With git, you commit your work, pull the remote branch, and then rebase ontop of it. It makes a lot of sense, and when your topic branch is indeed ready, you can push it upstreams, and the next rebase will merge the bits that have been accepted automatically. I just can't think of a simpler way.

Btw, we use svn at work, and I do use git-svn instead of svn to be able to develop my own patches without fearing conflicts in the same way I did before. I know I will benefit from the powerfull git merging capabilities and help at any stage, even if I did not pulled the svn for a long time. That makes the developpement much more sane, as I only try to push coherent changes, hence on a less regular basis. You could not do that without git-rebase. In that sense, git-rebase is anything but evil.