Stack OverflowWhy not use Git?
[+40] [29] Tom R
[2010-02-14 21:12:25]
[ svn git version-control ]

A lot of people like git (in particular this guy [1]) 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 [2], but I can't see any area in which other SCMs excel over git.

(5) Git is not a Content Management System (CMS) but a Versioning System. - Scharrels
(5) @Pascal SCM is actually Software Configuration Management git is a VCS (Version Control System) - anon
@Pascal Fixing Wikipedia is beyond me I'm afraid. And just because a VCS can be used to perform SCM doesn't make it an SCM (which would not even be grammatical). - anon
@Scharrels actually git is not a classical versioning system but a content tracking system which is one of the most important points which distinguishes it from other systems. - hurikhan77
(1) The official git website is, guess what?, so yea, it's an SCM. - hasen j
(3) My understanding of the terminology is that it is a "Source Code Management" system, and that this term is more or less equivalent to "Version Control System", "Revision Control System" and some other TLAs. - intuited
[+31] [2010-02-14 21:46:19] Heinzi

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.

(2) +1. I think this is the prime reason at the moment... - Macke
(2) how do you manage releases without branching? - jshen
(7) @jshen: You don't, really, but that's not the point. You don't need everyone to understand branching/tagging. It's enough that whoever is in charge of managing these releases knows it, and then when you really do need the developers to work on branches, you can teach them at that point. Introducing it too early in the process may be useful to them, but you don't really need to know that these things even exist in order to use SVN. With DVCS, it's a fairly big aspect, so you need to know at least something about it. Hence, it is simpler to learn about SVN - there's simply less stuff to learn. - Michael Madsen
(2) no, svn is not easier to teach. The steps maybe easier to teach, just maybe, but I never got my head wrapped around svn. OTOH, git made perfect sense to me. - hasen j
(1) Totally agree with @hasen j... svn is impossible to teach. Distributed is not the problem. Concurrent version control is the problem, if there is one. With SVN you ALWAYS hit up against the merging problem sooner or later. - Yar
Why do people assume a VC that focuses on branching will be harder to learn? For that precise reason, branches are one of the easiest things to do in git. Merging, pushing and pulling can be taught in under an hour. Whereas SVN treats branches as an afterthought, after a similar learning period git users will be able to create and merge dozens of branches with little difficulty. - rjh
(3) Has anybody actually tried introducing both git and svn to a group of people unfamiliar with either? I get the impression that people tend to think that the one they learned first is the easier one to learn. - intuited
[+31] [2010-02-14 23:06:47] Norman Ramsey

I'm going to go in a different direction than the many well-reasoned arguments about central versus distributed revision control.

  • Git lacks what Christopher Alexander called the quality without a name.

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.

(8) If you look at it again from another perspective, "push" and "pull" are opposites: You cannot push if you have conflicts upstream, as you cannot pull if you have conflicts in your working copy (but you could still fetch). But if you think in old non-git workflows you're probably right. - hurikhan77
(3) +1. What kind of design do you have when you name your product "Git"? - womp
(2) 1.) push and pull are not opposites because situation is not symmetric; in the case of pull you are there to resolve eventual conflict. Also the naming is from BitKeeper, I think. 2.) In just released git version 1.7.0 the default (which you can configure) is to refuse to push to checked out branch. 3.) Many git tutorials might also mean that the original (distributed with git) documentation was not enough; nowadays I think that "Git User's manual" is good enough. - Jakub Narębski
@Jakub: don't get me wrong, I'm far more productive with git than with any other tool. But when something as basic as "imprudent push breaks your repo" is not fixed until version 1.7, something is very wrong. - Norman Ramsey
@Norman: This fix waited for 1.7.0 (major release) because it is backwards incompatibile (if you know what you are doing, you can push into non-bare repository, but solution heavily depends on situation and cannot be safely generalized). There needed to be transition period. - Jakub Narębski
I'm afraid that I have to agree, for the moment at least. I'm currently looking at solutions for our department, and as much as I love git, I can't see how I'll be able to sell it to my colleagues. Do you know how to pull one file from a stash? Well it ain't intuitive, and you'll find the answer here on StackOverflow (thanks Jakub), not in the official doc. - Benjol
@Benjol: Let me know how you make out. My experiences with Mercurial and darcs have also been pretty painful. - Norman Ramsey
@Norman, bizarrely enough, I am currently pulled between git and Accurev, which are poles apart, but both avoid the 'branch as directory' confusion. - Benjol
(1) I think the reason for a lot of its eccentricities is that it was designed to be used primarily by people well acquainted with the details of its functionality. Making it palatable to the unacquainted was a goal not undertaken until after it had already become popular. This would seem to reflect positively on its usability. - intuited
@intuited: That was one of the most insightful comments I've ever read here at SO. - Dan Moulding
[+21] [2010-02-14 21:28:04] Yuval Adam


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.

(3) We had that situation at my company, but it didn't stop me from using git svn ;) - Charles Ma
(27) Ironically, that argument doesn't really hold water when you consider that Git enables centralized use as easily as it does decentralized. It's trivial to just add a remote which points to the main corporate repository. Or, even better, let your manager pull from you and s/he can push. I'm not saying that this isn't an commonly-used excuse to take a pass on DVCS, but it really doesn't make any sense. - Daniel Spiewak
(2) my company actually has their entire code repository under a single svn repository and different packages/projects are just sub directories of the main repository. migrating each project to it's own git repository and maintaining thousands of them would be a huge PITA. I'm not saying it's ideal, but this is our situation. git by design choice doesn't allow checkout of sub projects, but my organisation tends to depend on that ability. - Charles Ma
(6) Ironically this currently beeing the highest voted answer shows that the real reason for git not beeing used much also comes from the lack of understanding what git actually is and what kind of workflow it allows. Having a authoritative central repository is perfectly fine with git. - x4u
I will be fair and say that I do not know git inside and out, so that it might be fully possible to create a central repository that corporations are after. However, I know for a fact that many a SCM are reluctant to use git, and would rather prefer the time-tested-and-proven industry-standard tools. Might very well be a wrong or ill-informed decision, but nevertheless it is not uncommon not to choose git for enterprise development. - Yuval Adam
(2) A better excuse might be that Git doesn't scale up to the large-sized projects that are often seen in corporations; however, this can easily be fixed by good project modularization, and using a separate repository for each module. Good modularization also makes development easier, and helps isolate teams from temporary breakages in the repository (since a broken trunk will only affect the one project in question and not all projects). - Michael Aaron Safyan
(4) Doesn't scale up? Git seems to work fine for Linux kernel work, are most corporate projects larger than that? I haven't seen many. - Lyle
This argument does make some sense: if the repository is being monitored, anyone doing deep checkouts (many versions back) is going to raise alarms. Or at least if they're looking at it that way, if that makes sense for their software process. Whereas with git, it's entirely ordinary for the entire repo to be cloned. So if it's important to lock down old versions of the code (is this plausible?) then there's a point here. Otherwise I don't really see the value in it. - intuited
(1) Don't underestimate the number of less-than-expert programmers in most companies (at the very least there will be new hires). Sure, git can be used in a centralised way, but because of its flexibility, it's very easy to accidentally (or maliciously) break whatever conventions have been set up for centralised use. - John Bartholomew
[+20] [2010-02-14 23:14:18] Josh Stodola

The obvious answer is because I am satisfied with what I use now

I really wish I could +10 or even +100 here. I don't use git because Fossil does what I need -- more than I need, in fact! -- and doesn't have a user interface designed by someone with no taste. If I wasn't using Fossil I'd be using darcs or hg. I see nothing that git does that my tools of choice (which I'm already familiar with) don't already do. Why learn Yet Another Command Of The Moment? - JUST MY correct OPINION
@ttmrichter Thanks! I made it a point not to mention which one I use, because it really does not matter. It does its job, I am happy, I don't have time to worry about it any more! - Josh Stodola
(2) Command of the Moment? Moving to another VC is a non-trivial undertaking, yet git is used by the kernel, Perl, Qt, Rails,, Android, Debian, Fedora, GNOME - and KDE on its way. It is here to stay and (with github) likely the most commonly used DVCS around. So it's worth taking the time to become familiar with it. (Plus personally, I moved my projects from CVS to git and the difference is phenomenal) - rjh
[+16] [2010-02-14 21:21:39] Pascal Thivent

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.

(2) New-style DVCSs are far more superior in many aspects (not only when facing a possibility of disconnecting from central repo) than SVN (not mentioning CVS). Mythical learning curve isn't that bad (check out Bazaar, it have GREAT docs and tutorials and can follow typical centralized-repo workflow). - gorsky
(11) @gorsky Many companies are happy with subversion, have knowledge of it (usage, admin, etc), can support it and I don't see the point for them to throw all this away if there is no need. Subversion is good enough for SpringSource, for Hibernate, and many other projects so I do believe it's still good enough for most companies. This hype with Git is irrelevant for most of them (and the learning curve not so mythical given the current poor tooling support). - Pascal Thivent
(1) many companies were happy with snail mail and faxes, it doesn't mean that email isn't better for them. git is much better than subversion in many ways, the company i'm at uses both. The team that uses subversion works with multiple branches and then spends nearly an entire day trying to merge it into trunk when the time comes because subversion sucks so bad at it. Btw, they respond the same way you do because they don't understand what the difference is. - jshen
(1) @jschen I perfectly understand what Git is and use it myself but I'm not hypnotized by the over hype around it. Let's be realistic: people in the enterprise don't work disconnected, people don't branch that often (and not because the tool is bad at it), Git is not easy to use for most humans. Now, if your team is mature for it, fine. But that's not representative. - Pascal Thivent
(5) Disconnected access is not the main advantage to DVCS, though it is by far the easiest to explain. The real advantage is in ad-hoc peer-to-peer collaboration. I can new up a local branch for a feature and start making commits without disrupting anyone else. Maybe some time later, I discover that I need another dev's help with this feature. He can pull from me and collaborate on this feature branch still without disrupting the main repo. - Daniel Spiewak
(4) Another really huge advantage to DVCS which is often overlooked is it gives developer management the chance to implement strict commit policies without inhibiting productivity. For example, companies often mandate that the entire test suite passes before commits are allowed. This really slows down the commit cycle. However, with a DVCS, commits can proceed apace and the test suite run can be deferred until the changes are pushed. Access to this central source can even be restricted to a privileged few (think: managers). Ironically, DVCS gives corporate more control, not less. - Daniel Spiewak
(5) @Daniel My answer is not a rant against Git, I'm not saying that Git doesn't have superior features so there is not need to list them. My point is that many companies do not need these features so there is no point in training people to use them (yes, you have to train people to use Git). - Pascal Thivent
(1) @Pascal I wasn't listing features, I was just taking issue with your example case for not needing Git. I certainly will not contest the fact that some companies get along just fine with CVS or SVN and would only see a marginal benefit from Git. However, I don't think that disconnected access is a good example of Git's benefits or how they might not be required. - Daniel Spiewak
@Daniel Fair enough. I'll update my answer. - Pascal Thivent
@pascal I work in the "enterprise" and we use it just fine. I really hate the condescension with the "git is not easy for most humans". We're talking about programmers, not random people, and if your program can't understand git then you need a new programmer. I also don't buy this "companies do NOT NEED ..." argument. I don't even know what this means. Do companies NEED version control? There are companies that have made successful software without it! We know that most software projects are over budget or simply fail, so I think we do need to do better and better tools is a great start. - jshen
@jshen We're talking about programmers, not random people, and if your program can't understand git then you need a new programmer. I tend to agree... in a perfect world. But what about the real life? Do you really believe that all places are like the one you're working at? Everywhere? In my world, it's not the case, which is exactly my point. - Pascal Thivent
i just don't think git is that hard, and I don't think we give people enough credit. You draw a tree on a white board and say, "every one of these nodes is a commit". You then draw a couple of named pointers to nodes and say, "these are your branches, head, etc. When you do a merge of branch A into branch B it does a three way merge with the two pointers and the common ancestor." You then explain how working with remotes works just like this. If a programmer can't understand this then I question that they can write any code at all, but I truly believe they can understand this if they try. - jshen
@jshen No, companies do NEED version control. Companies that manage to produce successful software without a VCS are extraordinarily lucky. See McConnell's list of classic mistakes, #36 Lack of automated source-code control. Note that there isn't an item called "needed better tools" on the list. - Ken Liu
Well, some people do think that they don't need version control at all. - kolobos
[+12] [2010-02-14 21:27:45] Pavel Shved

"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.

(8) I am confused by the use of 'developers' in this context. It obviously doesn't mean what I thought it meant. - CurtainDog
(1) @CurtainDog, developers are the guys that create software: design, test, write code, etc. - Pavel Shved
(1) Pavel, I believe @CurtanDog's comment is meant to be tongue-in-cheek. And +1 for being very funny. - Jess Bowers
@pavel, your comment is offensive - hasen j
@hasen j, sorry if I take your comment too serious, but... hm, in what way is it? I don't see anything offensive there... - Pavel Shved
@pavel, relax, it's not offensive per se, it's just that, CurtainDog wasn't really asking "what does developer mean", if you know what I mean? - hasen j
(1) Unfortunately, knowledge of how to use a version control system isn't always taught to computer science students and the like. It isn't until they get into the real world that they eventually learn how to use one of them. - asmeurer
[+9] [2010-02-14 23:16:23] foxhop

Why not use Git?

Because hg mercurial exists!

(1) Could you at least say something about this? We know that it exists, but as GIT-user/Hg-ignorant, I don't know why I should care - Yar
That's it, I'm leaving Earth. - intuited
[+6] [2010-02-14 22:55:14] David Johnstone

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 [1] port or msysgit [2]. I haven't used either of them, but apparently msysgit is the better option, but it isn't yet a TortoiseSVN.


(1) There is TortoiseGit, and there is Git Cheetah, but I think that neither is as mature as TortoiseSVN. - Jakub Narębski
SmartGit is the best I've tried yet. - Benjol
[+6] [2010-02-14 21:51:40] starblue

Apparently EGit [1], 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.


On the other hand because of licensing issues (Subversion bindings are not EPL), and the fact that JGit is in Java, Egit promises to be better than Subclipse can be. Give it time... - Jakub Narębski
[+6] [2010-02-15 04:51:48] Craig McQueen

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.


[+5] [2010-03-04 00:43:50] JUST MY correct OPINION

I don't use Git because of the fanbois.


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:

  • SVN bites, yes.
  • There's way more choice in SCMs than SVN vs. Git.
  • The other non-SVN choices are easier to use than Git and support Windows better than Git.
  • "SVN or Git" is a false dichotomy [1].

<flamebait> Plus you dodge the drooling fanbois if you avoid Git. </flamebait>


I agree that most stack users tend to ignore the Windows world, large as it is. git happens to be the most popular DVCS at the moment and most people have moved from SVN or CVS. I think there's a general lack of understanding of the differences between git and other DVCS, so people use git as a representative of all modern version control systems. - rjh
With hg-git you can run mercurial and interact with git repos with no loss of data either way. Or even with mercurial repos. - intuited
And with just plain hg I can avoid git entirely. I know which way I'm voting. :D - JUST MY correct OPINION
[+5] [2010-02-14 23:06:25] Stephan Eggermont

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 [1]


Upvoted. Smalltalk would have no need for file-based version control systems. It's a pretty good reason to not use Git, snark in the answer aside. - kyoryu
I have heard noises on squeak-dev about interfacing with git:… - Frank Shearar
Thats the flaw (or "design decision') o Smalltalk, not Git. But it is a good reason for not using Git (or any other non-Smalltalk aware VCS) - Jakub Narębski
(1) I'm not well versed in Smalltalk. Can someone enlighten me as to what makes it a poor choice for use with Git? - Simucal
Smalltalk doesn't use text source files, it uses a binary image format(where the whole program state is saved as objects-in smalltalk everything is an object including all the classes). - Roman A. Taycher
Does it provide built-in version control or something? Or do you just use reflection to diff the objects in saved binaries? Or . . . something ..magnificent? - intuited
Smalltalk continues to blow my mind. - jbrennan
[+4] [2010-02-14 21:34:36] ufk

Check out the differences between SVN and GIT [1].

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.


You do know that DVCS systems were out long before git, right? That darcs, hg, fossil, bazaar (and many others) were out and in use long before git was a gleam in Linus' eye, right? And that any one of those does exactly what you're claiming is the Big Advantage of git, right? - JUST MY correct OPINION
thank you for enlightening me regarding the issue. the only systems that i used where git, svn and cvs. I'm a linux/mac user so i don't really need something with better support for windows. i would also prefer to use a repository system that's widely used so it will be easy for me to find support. i guess most people think the same and that is why usually you'll find comparisons of commonly used repository servers. - ufk
(2) @JMcO: Presumably git must have some advantage over the other systems, or it wouldn't have become so popular so quickly. Indeed, it likely would have never been created in the first place. Any idea why Linus decided to create git rather than use one of those other systems? - intuited
[+4] [2010-02-15 02:15:26] Macke

Because there's Mercurial [1], much easier for SVN:ers to grasp than Git. Better Windows support, etc etc. ;)

(couldn't resist.. )


[+4] [2010-02-15 02:18:42] kyoryu
  1. Because people don't understand distributed version control
  2. Because people are using another distributed VCS system and are happy with it (for me, Mercurial)
  3. Because people have evaluated distributed version control, and it doesn't meet their needs.

I've ranked these in order of likelihood.

[+3] [2010-02-14 21:41:36] thSoft
  • For people used to centralized version control, DVCS may be a big paradigm shift, which can increase cost.
  • Its commands are not always intuitive and may be risky.
  • Its tooling, e.g. the Eclipse team provider plugin is less decent than SVN's or even hg's or bzr's (this may change in the future).

[+3] [2010-02-14 22:26:06] Jason

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.

(5) You can migrate many VCS systems into Git preserving history. - Andrew McGregor
Hell, you can even preserve history from CVS, with pretty good detection of distinct commits! - Novelocrat
[+2] [2010-02-14 21:31:34] myfreeweb
..while the other DVCS might :P - gorsky
Bazaar is really easy ;) - myfreeweb
Mercurial is damn easy. - jpartogi
(3) Bazaar, hg, darcs, fossil: every single one of these is easier to use than git while offering all the benefits that have mattered to me. Personally when I'm forced to interact with a project using git, I make my local copy using git and then use fossil for local project management because I really can't stand git in about the same way (and for about the same reasons) that I can't stand emacs. - JUST MY correct OPINION
I find that link completely incomprehensible. I still understand how git works, but have no clearer understanding of the other available options. - intuited
[+1] [2010-02-14 21:25:41] Brian Rasmussen

I just had to pick a source control system for my various spare time projects, and I found the comparison at wikipedia [1] 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.


Codeplex supports Mercurial as well, and it doesn't support Git. - Jakub Narębski
@Jakub: Thanks for the info. I had it down to a choice between Subversion and Git and Codeplex support made me pick Subversion. - Brian Rasmussen
The git-svn tool is pretty mature; this lets you work with svn repos via git checkouts. It may be a bit confusing if you've not used git before, but once you understand them both it is quite useful to be able to interoperate between the two. - intuited
[+1] [2010-02-14 22:41:43] x4u

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.

Git Extensions provides a GUI, Visual Studio integration and the official command-line client: I've been using Git Extensions for a while without any issues at all, and am very happy with it. For some reason it doesn't seem to be as well-known as it should be. - Stuart Ellis
You might want to checkout out — this is a two-way mercurial-to-git bridge. The idea is that you can use mercurial (and its tools) to interact with git repositories in a lossless fashion. I have no personal experience with mercurial or with recent development on windows, but if it was worth building a bridge, there must be something over there. - intuited
[+1] [2010-02-14 23:39:47] Si

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 [1].


[+1] [2010-02-14 23:41:12] Ricosuave

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:

  • I prefer the simple Subversion commit numbers, though obviously it is not necessarily possible to use something like that with a distributed system because there is no "Singleton" to pass out the sequential numbers.
  • Using Subversion at work, when I need to ensure that everything is backed up, I just do a commit to my user branch. I don't necessarily need to worry about whether I need to create a checkpoint of any kind--I do that when I merge it back into the trunk line. But on Git, I am only committing locally, so I only do it when I need a checkpoint (for instance when I complete a goal or when I want to be able to roll back to a certain point). The local nature of commits does not do anything to back up. I have to manage backups and commits separately. In practice this means I commit a little less often, but it forces me to consider backup as a separate process. A quick git push to a remote repository and the whole shebang is backed up to my latest commit.

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.

I've already written this on here a couple of times now.... but anyway you might want to check out git-svn: this is a tool to enable use of git with svn repos. It's pretty thorough, including support for some aspects of svn that git doesn't itself implement. I'm not sure if it's feature-complete, though. .... re backups: you can set up a post-commit hook that pushes to some remote branch. ...... mercurial actually uses revision numbers: they are relative to a particular repository. - intuited
[+1] [2010-02-14 23:09:20] Eric

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

[+1] [2010-03-08 19:23:13] Arthur Ulfeldt

Git is harder to install if you are lacking privileges to install a compiler etc. I found mercurial easier in this case.

[0] [2010-06-30 03:10:36] intuited

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 [1] 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.


[0] [2011-02-06 05:45:35] Charlie Flowers

A Thought Experiment will clear this right up.

Imagine we live in a world that never had Git or SVN (and also never had any other DVCS). And tomorrow, simultaneously, by coincidence, both Git and Svn were released, each with their current full feature set and level of documentation.

Which one should you use?

Anyone who knows the facts and is being objective would have to choose Git. It does everything SVN can do and so much more, and it does most of those things better.

Therefore, back in our real world, it's clear that the only reasons to select SVN and promote it boil down to legacy ... because you already know it, or a bunch of developers you hope to hire already know it. It loses on every other front, and the only people who will dispute it are those long-time SVN lovers who felt that the world was just fine and we don't need all this damn progress.

The SVN era is over. SVN is a dinosaur. There is a new breed of version control systems that are clearly superior. Git is one of them. You can hold to a dying past if you want, but it is not rational and it is not going to be a rewarding choice for you.

[0] [2010-02-14 23:14:04] Josh Stodola

The obvious answer is because I am satisfied with what I use now

[0] [2010-02-15 01:51:35] Michael Aaron Safyan

In response to your question about Google Code not using Git... Google Code has considered using Git [1], 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 [2], but in the meantime, you can use Git's svn clone method to use Git with existing Google Code repositories [3].


(1) ...and "smart" HTTP support was added to Git only lately. - Jakub Narębski
[0] [2010-02-14 21:45:54] Nemanja Trifunovic

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.