There's a big difference between "not the official SCM system" and "a fireable offence". As a developer, I frequently use a pile of tools that don't have official support, because they help me get my job done more effectively than the "official" tools. Sometimes those end up becoming the official tools later, sometimes they don't.
But in any case, some of the issues you've listed represent bugs in development processes, not in Git.
> - People hiding their work in local branches where none of the other engineers can follow along.
Good developers using Git don't "hide their work" in local branches any more than they "hide their work" in an editor before they save it; sometimes you just have work in progress that shouldn't get pushed yet. (I certainly hope you have policies about when to commit, which include things like "the code compiles" or "passes tests" or "smells right"; if so, why aren't you concerned about people "hiding their work" in their uncommitted working copies?) If that work in progress has a sufficiently large scope that it needs more developers involved, then the branch may want to live in a repository accessible to others.
Before I had git-svn, when I had to work with SVN repositories, I ended up having several local copies of the repository, and doing the "small self-contained commits" thing manually by copying bits into and out of working copies. Git provided much more structure to that process, as well as making it faster and more efficient.
> - Getting massive rebased commits once every day (or worse yet, every few days).
Don't do that. You can and should push arbitrarily often.
> - An open-source Linux-inspired development model consisting of a massively distributed ecosystem of competing/disparate/intertwined branches.
If you have a project anywhere near as large as the Linux kernel, you'd be lucky to end up that well organized and optimized. But while you still have a team that can regularly communicate with each other on a list low-volume enough for people to read all the mails, you don't really need that ecosystem of hierarchical branches and repositories; nonetheless, you can get a lot of value out of Git even when using it with a single central repository.
But in any case, some of the issues you've listed represent bugs in development processes, not in Git.
> - People hiding their work in local branches where none of the other engineers can follow along.
Good developers using Git don't "hide their work" in local branches any more than they "hide their work" in an editor before they save it; sometimes you just have work in progress that shouldn't get pushed yet. (I certainly hope you have policies about when to commit, which include things like "the code compiles" or "passes tests" or "smells right"; if so, why aren't you concerned about people "hiding their work" in their uncommitted working copies?) If that work in progress has a sufficiently large scope that it needs more developers involved, then the branch may want to live in a repository accessible to others.
Before I had git-svn, when I had to work with SVN repositories, I ended up having several local copies of the repository, and doing the "small self-contained commits" thing manually by copying bits into and out of working copies. Git provided much more structure to that process, as well as making it faster and more efficient.
> - Getting massive rebased commits once every day (or worse yet, every few days).
Don't do that. You can and should push arbitrarily often.
> - An open-source Linux-inspired development model consisting of a massively distributed ecosystem of competing/disparate/intertwined branches.
If you have a project anywhere near as large as the Linux kernel, you'd be lucky to end up that well organized and optimized. But while you still have a team that can regularly communicate with each other on a list low-volume enough for people to read all the mails, you don't really need that ecosystem of hierarchical branches and repositories; nonetheless, you can get a lot of value out of Git even when using it with a single central repository.