These are not compelling arguments. In fact, these are terrible arguments, though I can see a kernel of truth, I think. Corporate America needs a centrali

These are not compelling arguments. In fact, these are terrible arguments, though I can see a kernel of truth, I think. Corporate America needs a centralized version control system. This is either a statement of fact or a thesis. If it's a fact, then the argument is circular. Subversion still offers this: Subversion centralizes the repository and simply checks out a working copy (versus Git, which gives you a complete repository). This is not an argument at all, but a description of how Subversion works versus Git. Corporate America still needs to have cannonical version numbers 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. ability to see the progress of a product over time as a single line - not a bunch of branches and independent repositories This is a workflow issue, not a problem with git. 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.