A lot of people like git (in particular this guy) against other SCMs such as SVN, but many projects, even new ones, are set up using alternative SCMs. Furthermore, Google Code still does not support it (although many of their large open source projects use it).
My question is: what are the reasons for not using git in any project, whether it be personal or collaborative? Maybe I've just been brainwashed by this guy, but I can't see any area in which other SCMs excel over git.
If a team doesn't know Git and actually doesn't need it (sounds like stating the obvious) because people don't use feature branches, because people will never be disconnected from the repository, then I don't see the point. Subversion will do the job without the learning curve and with better tooling support.
I just had to pick a source control system for my various spare time projects, and I found the comparison at wikipedia very useful. I ended up picking Subversion as I got the impression that it would be the easier to use with Codeplex projects. However, I am sure Git would have been an excellent choice for me as well.
"Git? What is Git?"
That's not me asking, that's the reason. We didn't use git in our recent project because none of the developers knew how it works and didn't want to use its advantages. So we picked Subversion. It later appeared that they didn't know how to use Subversion as well, so the choice really depends on the time a particular SCM was around. Git just hasn't been out there for long enough.
Decentralization
Large corporations (usually) want to keep very tight control on their stuff. It's their cash cow, and they can't afford any mistakes with it. Most corporations will go with a central repository, which is backed up and monitored rather than a distributed landscape which you have much less control over.
That right there is the main reason you don't see git in corporate or enterprise use.
Git is not easy to use. http://en.myfreeweb.ru/why-git-is-not-better-than-x
Check out the differences between SVN and GIT.
Some people explained that Git hasn't been out long enough, and they're right. I've been using SVN for many years, and I only recently moved to git.
For my usage, Git is a lot faster. Having all of the repos in my own system makes my life a lot easier whenever I want see my code's previous state.
Git allows local commits, which is a really good thing. I often want to commit when disconnected from the main server, in order to save my work.
At work I don't decide which SC system to use. When I started my open-source project, alternatives were CVS and SVN and I went with SVN. If I started a new project from scratch I might consider Git, but porting the existing one from SVN is not something I am interested in.
Non-distributed VCSs like SVN are easier to understand and to teach: The concept of a revision number is easy to grasp, and the "check-out, edit-your-stuff, commit" workflow is easy to teach.
Sure, git is much more powerful, but there are cases where distributed version control or any other of the advanced features git offers is just not needed. I've just had the case of a team of junior developers that neither knows nor cares what a branch is and just wants to get on with their coding. Making them use a VCS at all was hard enough and I was quite happy that SVN had a low entry barrier.
Apparently EGit, the Git Eclipse plugin, is not yet ready for prime time.
Subclipse works very well, so I use that with a local repository for most of my personal projects.
There is a cost associated with transitioning an established company (50 developers or 5000) to another software package of any kind. In the example of a VCS, you lose history if you just take a snapshot and start over. You also have to teach everyone to use it and put up with the inevitable errors and lengthier development cycles as people figure it out. You also have to train or hire a subject matter expert to figure out the corner cases for everyone.
If the current VCS is doing "good enough", you won't see a given enterprise transition to it. It's the same reason people (usually) don't rewrite their software in the most recent cool language/platform everytime one comes along.
I think some of the reasons for this are:
The available tools are not very advanced and mature yet, especially on Windows. There are many of them but most are either incomplete, buggy, ugly or all of this together.
Some people just like other version control systems or just got accustomed to them and most importantly trust them to be a safe place for their code or at least know how much they can trust them.
Many companies have a workflow that is based or otherwise tied to a particular version control system. I.e. bugreports refer to it, it's integrated in the development process or build scripts etc... This makes it not an easy change to switch to something else.
For me personally it's the lack of a decent GUI-tool for Windows and that holds me back from going on a missinary spree for git. I really like a lot of things in git and I hate Subversion and Co. almost as much as Linus does but the git environment is simply not yet ready to be a tool for everyone.
Also I still don't fully trust it. Will I accidently break my local repository or delete important stuff because the tools are either buggy or I didn't use them correctly? What is if my repository gets corrupted somehow? Sure, it won't silently hand out corrupted files, but would I be able to get at least some pieces restored. A backup from 3 days ago can sometimes be way too old, and to be honest I rarely have a backup that fresh.
But still I'm sure it will replace most version control systems in the near future and will cause a decent productivity boost for many projects. It's a big step in the right direction and has the potential to improve the way we work with code a lot.
From an ease-of-use standpoint: Git is not yet well integrated into Windows/Windows applications. It is possible to use it with Windows, but AFAIK, the best ways to do it are to use the Cygwin port or msysgit. I haven't used either of them, but apparently msysgit is the better option, but it isn't yet a TortoiseSVN.
We use smalltalk, and have no need for antiquated file-level source code management...
It all depends on the process you need to support, and the platform. cvs, svn, git, mercurial, vss, tfs all only manage source code reasonably well. If you have a need to manage different related artifacts (product data management) something else is needed.
Take a look at managing design data
I'm going to go in a different direction than the many well-reasoned arguments about central versus distributed revision control.
While the "plumbing" is a miracle of efficiency and clever engineering, the "porcelain" lacks intellectual coherence, makes promises that it can't deliver, and just generally is not satisfying to use. It's like a hammer that's out of balance.
Supporting evidence:
What kind of design do you have when push and pull are not opposites? (The opposite of push is fetch, and pull means "fetch then merge".)
Git cheerfully promises push changes to any repository. And if that repository happens to have a checked-out working directory with changes, the repository is now broken.
The fact that so very many git tutorials have been written indicates that something is wrong with the design.
That said, I use git, even relatively enthusiastically, because the alternatives I have tried are even worse. But I don't recommend git to others, or if I do, I recommend it reluctantly and apologetically.
I have everything setup with SVN, it does what I want and it works.
It isn't broken... yet, I don't need any fixing
The obvious answer is because I am satisfied with what I use now
The obvious answer is because I am satisfied with what I use now
When the non-programming people in your company also use a revision control system, and you don't want to maintain two systems, or explain the differences between a centralised verses distributed system. More details.
I use subversion at work, and Git on personal stuff. There are many times at work I'd rather be using Git, but I have never (on my personal stuff) said that I wish I was using subversion. If you forced me to make some Git gripes, I would list:
Otherwise, I find the command line use of Git (even in windows under the Cygwin interface provided) to be simple to use--and the git gui is more or less as nice as svn in eclipse (and almost as nice as the tortoise svn system).
If our team were starting out now, we would probably pick Git over SVN--at least I would push for it and I know some others would, but I am not the guy who gets to decide that stuff. A few years ago we switched from CVS to SVN with a little pain involved, so I doubt that anyone will be interested in jumping on it now.
In response to your question about Google Code not using Git... Google Code has considered using Git, however, the inefficiency of its HTTP transport resulted in Mercurial being selected over Git. There has been some speculation that Google Code may eventually add Git support to Google Code, but in the meantime, you can use Git's svn clone method to use Git with existing Google Code repositories.
Because there's Mercurial, much easier for SVN:ers to grasp than Git. Better Windows support, etc etc. ;)
(couldn't resist.. )
I've ranked these in order of likelihood.
Unicode file names
msysgit on Windows is not good with Unicode file names. See:
On Linux, git should work okay if you mandate that users use UTF-8 for their system filename encoding. Well, it should also work if all users all use some other encoding, as long as everyone uses the same one. But for long-term sanity, don't use anything other than UTF-8.
I don't use Git because of the fanbois.
</flamebait>
OK, seriously, I don't use Git because I've not seen a single persuasive argument to move me from Fossil (or Mercurial (or Darcs (or Bazaar (or ...)))) to Git. Most of the people I've seen drooling over Git dropped Subversion for Git and think that Subversion was the State Of All Things SCM Before Git and thus make attacks on "other SCM systems" that are uninformed at best, outright deceitful at worst.
Is Git better than Subversion? For most use cases involving technical users, Hell yes! This is a classic case of damning with faint praise, however, since, as far as I'm concerned, making diffs by hand and storing them in a hen house out back behind the barn is better than using Subversion. Any distributed SCM will be better than Subversion, and the ones I named above (Fossil, Mercurial, Darcs, Bazaar), along with several others, will all be both better than Subversion and a lot easier to use than Git.
Others have also pointed out that if you do any work on Windows you'll find that work a distant second class citizen (verging on serf) in the world of Git. In the world of Fossil, Mercurial and, I think, Bazaar, you're a fellow citizen, albeit, in some of those communities, a bit of a retarded one. (I'm not sure what Darcs is like under Windows having never had the need to find out.)
TL;DR summary:
<flamebait> Plus you dodge the drooling fanbois if you avoid Git. </flamebait>
Git is harder to install if you are lacking privileges to install a compiler etc. I found mercurial easier in this case.
I'm definitely much more in the git camp than the svn one, but there are a couple of features that svn has that are not available, or not entirely supported, in git:
checkouts of a particular directory. To get this in git you have to create a submodule in that directory, and you have to make that change in the repo that people are pulling from, and it's kind of complicated, and involves using filter-branch if you want to do it on an existing repository. With svn you just check out the directory. There was rumoured to be somebody working on this feature, and more, for git as a summer of code project a couple of years ago, but it doesn't seem to have gotten anywhere.
revisioning of file metadata. With git you can set up a commit hook to save this sort of thing. there's a script distributed with git in /usr/share/doc/git-core/contrib/hooks/setgitperms.perl that will save permissions and ownership data with each commit. SVN as I recall has richer support than even this script provides.
As for the others, I'm not too clear on the differences; the advent of lossless bridges like hg-git has made it questionable that there even are any meaningful ones in some cases. hg-git is a bridge capable of bidirectionally transferring information between a remote git repo and a local mercurial one. So at least topologically, they are equivalent. Presumably the interface syntax is not a particularly significant factor in the system itself. That being said, I've not really used mercurial, nor bazaar, darcs, etc., in any meaningful capacity. Some are rumoured to have better gui tools and integration with IDEs that I also don't use.
I am interested in learning more about the other DVCSs. However, the common wisdom (and this thread is no exception) seems to be simply that they are "easier to learn," with the assumption implied that no further explanation is necessary. Details are seldom, if ever, provided, and I am left to wonder if perhaps the speaker found them easier to learn because they learned them first and have a mental model based on that tool.
I'm aware of some of the differences — for example, in mercurial, there is normally no difference between a branch and a repository (if I remember/understood correctly). However I've not learned anything about any of the other DVCS that would indicate a clear advantage in terms of usability and learning curve. Personally I find the idea that a repository does not normally contain branches to be, if anything, more confusing than the alternative. This is almost certainly because I learned git first. However, of the things that I found confusing about git when I was learning it, the concept of a repository containing multiple branches was not one of them.
I do find it confusing (and annoying) that a directory cannot contain multiple repositories at its root, or a repository contain multiple orthogonal sets of branches. These two possibilities would equate to more or less the same thing, and if another DVCS facilitates this functionality, that would be of no small interest to me. But my tentative sussings-out of the alternatives to git have thus far not yielded any such delectable fruit.