Exactly. The kernel community has lots of wisdom built up around rebase vs. merge, and the way I think about it is, imagine a tree of developers with Linus at t

Exactly. The kernel community has lots of wisdom built up around rebase vs. merge, and the way I think about it is, imagine a tree of developers with Linus at the top, maintainers in the middle, and leaf nodes at the bottom. - leaf nodes can and should rebase to ensure whatever they submit is "bisect clean" - everyone else should never rebase because you'll destroy history As a leaf node, you should always be committing and submitting the cleanest patches possible. The prime directive is "do not break bisect". There's much more wisdom in: http://www.kernel.org/doc/Documentation/SubmittingPatches http://www.kernel.org/doc/Documentation/SubmittingPatches stgit is a nice tool to manage your patches as a leaf node. It lets you go back and clean up individual patches in your history so that everything you submit is clean. Maintainers don't rebase, period. And recently (past 18 months or so), Linus has been yelling at them to not merge from mainline back into their proposed branch before pull request. The rationale is that when you do so, your pull request is now based on untested code. Most dev communities will never scale as large as lkml, so not all the lkml conventions make perfect sense to adopt. However, like I said, there is still a lot to be learned from the community that's been using git the longest and pushing it the hardest.