These are not compelling arguments.  In fact, these are terrible arguments, though I can see a kernel of truth, I think.<p><pre><code>    Corporate America needs a centralized version control system. 
</code></pre>
This is either a statement of fact or a thesis.  If it's a fact, then the argument is circular.<p><pre><code>    Subversion still offers this: Subversion centralizes the repository and simply checks out a working copy (versus Git, which gives you a complete repository).
</code></pre>
This is not an argument at all, but a description of how Subversion works versus Git.<p><pre><code>    Corporate America still needs to have cannonical version numbers
</code></pre>
The version numbers in Git are fundamentally canonical.  There is a possibility of hash collision, of course, but that's not a real concern of anyone.  If the Kernel can work with hash numbers and not have collision issues, then a large corporate product can too.  If the argument were that the version numbers must be incremental, I might accept that, but I would like an explanation as to why.<p><pre><code>    ability to see the progress of a product over time as a single line - not a bunch of branches and independent repositories
</code></pre>
This is a workflow issue, not a problem with git.<p>Fundamentally, I see corporate objections to git entirely as a lack of established workflows and repo server management tools.  Gitosis is nice, but I don't believe it allows for the central control that IT managers want.  Also, people have not written O'Reilley books about how to manage a git server in a corporate, centrally controlled environment.