I like the idea, except I'd prefer an option to rebase rather than merge when my code is out of date relative to upstream. Merge is for when a major line of de

I like the idea, except I'd prefer an option to rebase rather than merge when my code is out of date relative to upstream. Merge is for when a major line of development departs. A minor feature written by a single developer is better as a rebase because it makes your history easier to understand. Some people are purists who say "But that destroys history! It wasn't what actually happened!" Say that you implement Feature X. Six months later you want to implement Feature Y, and you say "I know that Feature X is similar enough to Feature Y, so I want to consult the patch for Feature X to see some working code that hooks into the interrupt vector table." You don't want to see a sequence of six patches against different master commits, the first five of which don't even compile. You want to see a single clean patch. If you don't squash and rebase unclean patches, you're hobbling future maintenance that needs to look at that code. You don't want to use Git to preserve what actually happened unless you're a historian. If you're a developer whose main goal is to get stuff done, you want to use Git in a way that makes the code as easy as possible for people unfamiliar with it to understand -- and months or years from now, your future self will probably be somewhat unfamiliar with the code you're writing today!