<p><pre><code>  Corporate America still needs to [...] see the progress of a product over time as a single line – not a bunch of branches...
</code></pre>
"Corporate America", insofar as it is a singular monolithic entity with no cultural difference, should realize that their product IS the result of "a bunch of branches", and that git, over subversion, is a tool to help people work more efficiently because it realizes this, and helps you manage them. It changes version control from an annoying thing that you have to deal with, to a tool that helps me not worry about various details of version control, but instead deal with the problem at hand - the product. The sheer existence of git-stash sold me, and while I'm handy enough to use "svn diff &#62; changes.patch" with "patch &#60; changes.patch", git just is generally a better tool for that.<p>The biggest benefit of git, over svn, I'd argue is actually branch merging and merge conflict-resolution capabilities. Subversion 1.6, however, is supposed to take leaps and bounds to catching up to git (vs. the 1.4 server install I currently work with). The version numbers in git are less intuitive than svn, but I feel thats okay, because tagging is useful in git. The real win for git, is that git works with you and your workflow, and doesn't impose as much workflow as subversion does.<p>( git-svn absolutely your friend. )