[burgerbrain]

Nothing about git makes it either "social/public" or private. You can use it yourself entirely on our own workstation, you can use it on a company server only your devs have access to, and you can of course make public repos on your own hardware or with hosted solutions such as github.com.

Git is also arguably more secure than many other VCSs since it (in a very very small and generalizing nutshell) works by creating a directed graph of SHA sums. You can't change a file and propagate those changes to other people without everyone being well aware of what has been done. Not unless you can compute useful code that collides with existing code... check out what linus has to say about that improbability some time^ ;).

No, security shouldn't be the issue for enterprise companies, though scalability is often cited as a potential issue. If you currently use perforce to a heavy degree, you might have some issues with going to git. This is not to say that git cannot work for very large companies, it probably just isn't going to work well if you put every project in your large company in a single one or two repos (as many companies do with perforce). It'll handle large projects fine however, it handles the linux kernel like a breeze.

^ http://osdir.com/ml/version-control.git/2005-06/msg00583.htm...

[exDM69]

Using a giant repository (like some people do with perforce or even svn) is not a smart move with Git. In fact, I think that it's even mentioned (or at least used to be) in the Git documentation. I've read more than one disgruntled blog post about someone who dumped their entire 60 gigabyte Perforce repo (full of binaries) to Git.

These days you can use git submodules which work quite nicely.