It's a bit frustrating that the whole "never rebase" thing has become a cargo cult -- because it's only correct in specific circumstances (thus it's completely

It's a bit frustrating that the whole "never rebase" thing has become a cargo cult -- because it's only correct in specific circumstances (thus it's completely wrong to say "never"). The reason why the Linux kernel has a no-rebase policy for maintainer trees is that thousands of developers base their work on the maintainer trees. Developers are constantly rebasing their work (either to update to the latest development branch by a maintainer, or to restructure and modify their commits with "git rebase -i"). Thus, rebasing maintainer trees would result in many developers having to deal with frustrating issues when they rebase (they have to curate which commits the maintainer has removed to keep with "git rebase -i"). It addition, maintainer trees get tested automatically and rebasing a tree invalidates all of the previous testing (so if you ask Linus to pull from you and the tree was just rebased, you're sending untested code and will get shouted at). Yes, you should never rebase master -- because there is guaranteed to be more than one user of master. But rebasing (for developers working on a feature) should be a very familiar thing to do -- unless you're working on a feature branch with someone else.