When in the course of human events it becomes necessary for a software user to disparage a thoroughly hostile
- git has destroyed our data.
- git has destroyed our data remotely.
- git has forced us to learn gitology.
- git has coerced us to memorise --many --unrelated --options. For suposedly the same command.
- git has made us use a thoroughly unintuitive user interface with badly named commands.
- git has produced horrible documentation.
- git has written and suggested we read Git for Computer Scientists. Several times.
- git has created the largest unavoidable worldwide gang of users, and we must use git if we wish to collaborate with them.
- git has obscured safer, easier, and just as powerful alternatives.
We, therefore, appealing to the wellbeing of all software users, do in the name and by the authority of all distributed version control system decency, solemnly publish and declare that git really fucking sucks, that the previous obscene intensifier was fully necessary, and that we should do all that is within our power to reduce and minimise the proliferation of git usage.
Why I must write this
Before I proceed with my study of git hate, I must first present an apologia for why I am writing this.
You may tell me, “fine, you hate git, don’t use it. It’s just your personal preference.” Normally, for any other software I use out of personal preference, I would agree. I am a student of the Church of Emacs, but this does not mean I think everyone should use Emacs. As long as you produce text, I don’t care how you do it. You can use your text editor of choice, I can use mine, and we will both be happy doing so.
Unfortunately, the same does not hold for git. Although git can be used in isolation without ever collaborating with anyone else (after all, it is a distributed version control system, so this makes it easy to use without other people or a remote server), this is not its primary use case. If everyone around me is using git, then I am too coerced to learn git if I want to collaborate with their software development. You may argue that I can use another DVCS because everything can convert back and forth to git, but interoperability can only go so far. Eventually someone uses a feature of git that another DVCS doesn’t implement, and I will have to use git anyway.
Moreover, it is clear that git is creating a community of people who are faffing around learning gitology and feeling good about themselves for understanding abstruse concepts which are completely orthogonal to actually getting work done. This is evidenced by all the blog posts written by people being frustrated with git. As the renowned 20th century mathematician G. H. Hardy once wrote, “it is a melancholy experience for a professional mathematician to find himself writing about mathematics. The function of a mathematician, is to do something, to prove new theorems, to add to mathematics, and not to talk about what he or other mathematicians have done.” In a similar vein, it’s a melancholy experience that we spend so much time blogging about how to use git, reading blogs about how to use git, and joke about using git, instead of getting work done. Without git.
Because everyone else is wasting their time praising and discussing git, the aptly-named stupid content tracker, I must now waste my own time to point out how blockheaded it is that we spend so much time learning the tool that should be tangential to our work and ultimately unrelated to our actual work.
What will not be hated on
I want to make it perfectly clear that I will direct my hatred at git and at git only. In particular, none of the following will receive any direct dosage of hatred:
- github
- magit
- git Tower
- gitg
- TortoiseGit
- Your Favourite non-commandline Interface to Git
- Whatever other tool for tracking content that happens to use git as a database or whatever
I want to make this clear, because these tools above are the reason many people claim to love git. But just because good tools have been built on a horrible core doesn’t mean the core is good. As an example I will frequently come back to, C++ is a horrible language, but many good tools and frameworks have been built on top of it.
To all the hardcore git lovers out there, git is neither necessary nor sufficient for building all of the tools you probably love that have been built on top of git. The facilities git provides to build these tools on top of it could have been provided by any other DVCS. We can and should do better than git without sacrificing any of the things you love about git, other than whatever tool has been built on top of it.
Furthermore, I also want to make this very clear: the ultimate enemy is centralised version control, not git. CVCSes are what’s really slowing our collaboration down. git is only the major enemy within the DVCS camp, but if you’re forced to choose git over any CVCS, and git is really the only choice for a DVCS for you (this is rarely true, but I’m speaking hypothetically here), then, yes, choose git. It is by far the lesser of two evils in this hypothetical Catch-22.
What will be offered instead
I will frequently cite Mercurial, abbreviated hg, as an alternative to git. I contend that Mercurial is a safer, saner, better designed, and no less powerful alternative to git. While it may be true that Bitbucket, the major non-free provider of Mercurial hosting often compared to Github, may not fulfill the requirements you have come to expect from Github, this is not due to any limitation of hg itself. As I said, I want to only argue that git as a building block is rotten, but this is not directly related to how people have managed to polish this particular turd.
I do not, however, want to be taken as simply a an admirer of hg who is used to an hg workflow and thus hates git simply because git is not hg. I will make a thorough effort to present sound arguments for the myriad reasons why git sucks that will stand on their own without comparing them to hg. When I am finished expounding my revulsion for git, I will offer alternatives that hg or perhaps another DVCS offers that demonstrate that git’s ugliness is not necessary.
Necessary. This is also a word I will come back to often. A central theme of my attack is that is that all the complications that git has created are not necessary. In order to demonstrate this, I need to offer examples of where git’s equivalent functionality exists without the parts of git that are not necessary. This is why I will frequently cite hg.
So, enough with the meta. Let’s get on to the hating itself.
bring on the hating facts! we have had so many git snafus at work, Id love to have some clearly factual ammo to bring it down.
Hi Jordi,
Great post! I’ve also waste so many time learning all the philosophy around Git. There are lots of videos, presentations, complicated stuff to just learn the tool for basic usage. It’s cool to learn about all those things, but it’s not productive as you said. The Git approach is something like:
“You want to count? Ok, but you first need to read about Peano’s axioms, well ordering, …, after that, you’ll be able to find the successor of 1. And you can do it in several ways, by the successor function itself, by the induced + operation, …, but be careful, 1 is not the sucessor of anyone!” o.O
Today i see Mercurial as the best DVCS, maybe because i don’t know much Git. One fact i really dislike about the last is that it’s developers forgot one of the most important principles in programming: KISS!
Regards,
Júlio.
Tell it. Git was forced down my throat at work by a zealot. And frankly many of its tools are less polished than even those available for – wait for it – SVN!
GitHub may be great for open source but there’s no way I’d be allowed to use such a thing for corporate development. So Git’s sole advantage is effectively nixed for us.
Another thing to note – centralized repositories may suck for widely distributed open source projects, but my work setup with Git is actually kind of contrived when you consider that for backup, escrow, legal, and other reasons we have to have a ‘central’ git repository anyway – if only so that the official ‘blessed’ builds come from the official ‘blessed’ build machine with the official ‘blessed’ code signing.
That said, Hg is my favourite as well.
Same here! GIT is being forced down our throats. We are using a DVCS, GIT, but told by management, use it just like Subversion.
So far, I’ve managed to delete the repository, create a repository inside of an existing repository, committed my changes that somehow deleted everything in the repository that I didn’t touch (but my changes were there).
I have a web page I go look at after doing a GIT PUSH to see if my changes actually arrived to the remote repo and to verify that GIT didn’t do anything else.
Preach it brother. It’ll be a great day when github decides to support mercurial and I can quit using git but gain the benefits that github.com provides.
Awesome. Pretty much everything I tried to say in my post (http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/) but much more eloquent. And vociferous :) But then, you’ve had longer. I’ll get there.
I couldn’t agree more.
What bothers me most about Git is the impression that it is giving to Subversion and TFS users about distributed version control in general. Its unnecessarily steep learning curve, its inability to abstract away its internals, its insistence on second-guessing you (e.g. git merge which automatically commits, git pull which automatically merges and commits), and its strongly command-line-centric culture make for a pretty rocky ride for new Git users, and that, combined with the aggressive zealotry of Git fanatics means that on many teams that adopt Git, the majority of developers are deeply unhappy about it.
Take a look at amplicate.com, for instance (http://amplicate.com/hate/git): it’s saying quite something that it has more “hate” votes for Git than for Subversion and TFS combined, even though TFS (which has absolutely appalling usability) has about 1.5 times as many users as Git, and Subversion still has about three times as many.
There’s been a pretty rapid uptake of Git in the second half of last year in corporate shops, but I wonder if we’re about to see a backlash against it from everyday developers saying “enough is enough” to the fanatics and throwing it out en masse. I think this is badly needed to bring the Gitterons back to reality, but unfortunately, no doubt many of them will end up tarring Mercurial with the same brush, and entrenching themselves even further into the (perceived) safety of SVN and TFS.
Meantime, here’s an interesting statistic for you: according to ohloh.net, 54% of open source projects still use Subversion and 12% still use CVS. http://www.ohloh.net/repositories/compare
Yeah, I’m really concerned with how git is giving DVCS a bad name. I wish people realised that DVCS doesn’t have to be git, and it doesn’t have to be like git. Even bzr, despite its other flaws, has some advantages: it lets you use it in a centralised manner until you’re comfortable being distributed. Mercurial also does this.
In fact; that’s how we used hg in the major project I contribute to: GNU Octave. Now we’re branching all over the place with Mercurial, but close to two years we first used it in a mostly centralised matter. I still get people coming from svn who find the current branchy workflow with hg a little bizarre, but not too bad. It helps that all the basic hg commands are named the same as svn.
Git excercises a social loophole:
Having the kind of complexity it does, git requires an extremely quick and agile mind to use, or at least to learn in a reasonable amount of time.
Quick and Agile are hyped as the best minds for programming, but that is often not the case. Deliberating, calculating, and comprehensive minds are equally if not more important.
Knowing they’ll look like fools, the deliberating, calculating, and comprehensive minds choose to keep their mouths shut when it comes up in an argument, because arguments aren’t generally their forté.
It’s my opinion that Mercurial is a superior group organization tool, based on experience watching how git affects a group’s capacity to interact as opposed to how more “friendly” version control systems such as Mercurial do. Mercurial is a tool that can easily be used by both kinds of thinkers, and adds to the productivity of both, whereas git is a tool that can technically be used by both, but only significantly adds to the productivity of the first group, and sometimes detracts from the productivity of the latter.
..that latter group, by the way, is the one that is much more likely to spend time making sure your code is actually stable and well-integrated, and that the corner cases are covered.
If you’re a project leader, you’d be wise to choose Mercurial, and if you choose git, you’re probably going on pressure from your ‘best and brightest’ which probably amount to roughly a third of your productivity. If others voice complaints, pay attention to them. Git is not technically superior to Mercurial, and Mercurial *is* a superior tool for getting a complete team to work well together.
I hate it too, still an academic thing and my company will use for projects just because there are some huge fans and it is free source control. We would save a lot with TFS, shure we have to pay for it but then full integration with visual studio and all the work methodologies and all sort of working reports and tracking and so on.
We have to loose alot of time that we should use for developing the projects. Almost all tutorials are about using a local or in same network GIT, and about web server? ssh configuration and such sucks, since there is no tutorial explaining how to connect a configure that for GIT!
And then when I ask for a manual to that huge fans they dont give me, they only say: “there is the server, you have access, just use it”. I dont have time to learn it, I am concerned about and concentrated in the projects I invented. Please !! GIT concerned people, just post a manual where you say how to intall, configure and work with in a concise list of configurations and commands as a hole, for working with a project! Most manuals are loosely coupled arround the web and diffent versions and applications.
GIT seems CVS but with alot more confusing information.
CVS and TFS are all centralised. The problem with centralised source control is that you can’t experiment without stepping on everyone else’s toes. Distributed version control lets you experiment wildly without stepping on anyone else’s toes, but it comes at an inevitably higher learning curve. However, the curve doesn’t have to be as bad as git makes it out to be. Try reading Hg Init, which tries to explain DVCS in the context of Mercurial. However, even if you’re stuck using git, I know a number of people have found Hg Init to be a clear explanation.
The only problem you’d have then, is that you have to learn the git UI, which is really where all of my own hatred is concentrated…
I can create branches in CVS and it doesn’t step on anyones toes. Why do you say it is stepping on someone else’s toes? If I create a new branch using CVS another developer does not even know I created it unless they go and look for it.
Maciej Zawadski, developer of the world’s very first build server, Anthill OS, encouraged me to create a branch for every single feature. I still do this at times, having 6 or 7 branches of a single project in my workspace at one time, but most of the time branching for every feature is overkill.
Git was pushed down our throats in the place where I work: I like the concept of it but not the execution – this freaking thing NEVER WORKS as expected.
Every time, there is a problem, and I mean every time, daily! And every time, to fix the problem you need someone with a PhD in git, to run some insanely obscure and complicated commands.
Git is garbage, it just does not get the job done, not to mention it is insanely complex and the complexity is not hidden behind a clean and simple interface, instead it is thrown
Git is literally killing my career. I had to leave work the other day and went to the doctor basically telling him that I think I’m having a nervous breakdown. I’m back at work today and have been fighting git all morning just to get other devs’ latest changes merged with mine. I have to say that although for all these years I’ve been citing Microsoft Word as the worst software ever written, Git is easily number 2 and fast approaching the top spot. I’m typing this in the bathroom at work, wondering how the hell I am going to get through the afternoon.
You really shouldn’t let git get to you like that. It’s bad, but it’s not that bad.
I used to hate git too, before I really understood it. Now I feel it is peerless. And remarkably, I now think it is the simplest, most intuitive tool in existence. Yes, the commands are verbose, but that’s just syntax. The underlying concepts are so elegantly simple that it strikes me as quite perfect now.
Part of the problem is in trying to pick it up from snippets on StackOverflow. Git is in general terribly explained, so skip all the half-explanations and just read Scott Chacon’s free git book. That’s all you need, plus a little local experimentation to gain confidence.
The problem with hg is its branches — they’re not as flexible as git’s. Once you realize git’s branches are really just plain old pointers that can be picked up and repointed anywhere you like (without any affect to the underlying committed content), the world opens up.
I frequently get the argument that if I don’t like git, it’s because I must somehow not understand it, that to understand git is the same as liking it.
Of course I can understand git and still dislike it. I know how its branches work.
But I don’t dislike its internal data structures, which is what everyone seems to praise the most. There’s nothing genius in them: Mercurial’s revlog is just as smart and interesting. The blob-tree-commit-ref model is fast for some things but slow for others (e.g. git is much, much slower than hg for clone and blame operations).
My complaint with git is that its UI is terrible and it makes people think in certain ways that are somewhat inflexible. For example, any operation that changes existing commits in git is called “rebasing” just because “git rebase -i” is the command to perform these editions, even when there are no commits changing base. Then this language gets propagated into other things, such as the belief that Mercurial branching is inflexible just because it’s not named like git.
No, Mercurial branching is not inflexible. If anything, you have more ways to branch in Mercurial than in git: anonymous branches, named branches, bookmarks, and just plain ol’ clones. Mercurial gives you the tools to build any workflow you want, which includes git-like branches as a subset.
Thanks for this post. I agree, git is not ready for prime time. I spent many hours setting up a private git repository on a cloud node then getting Eclipse to work with it. What blows me away is that for every new software project I create in Eclipse, I still have to login to the server and initialize a new repository! Are you kidding me?
I installed CVS using apt-get, created ssh keys, configured the CVS repository in Eclipse, disconnected all my git repos and re-shared them as CVS modules all in perhaps 30 minutes. The feature of easily setting up a shared repository is the one feature that is sorely lacking with git and makes it a huge burden to use.
Can I ask a silly question about DVCS? If putting my applications out on a cloud node is better than running them locally, if sharing my fishing pictures on Dropbox is better than having them local, if literally everything else on the entire internet is better when it is shared…. why is distributed version control better than centralized version control? I am not afraid to create branches in CVS, change branches in my workspace, merge, rebase, create patches, or anything else I need. I’m not missing any features I want from a version control system.
So what is the killer feature with git again? The branch is local so nobody else can see it? It’s faster to change branches so I can change a branch in git in 1 second rather than 10 seconds with CVS? I can “commit” code to a local repository even if I’m disconnected from the internet? Frankly, none of these features is the least bit compelling. I don’t feel the need to hide any of my branches from anyone, I don’t feel restricted in any way from creating branches with CVS, I haven’t had any problems merging code from multiple branches, and I am almost always connected to the internet when I’m developing code.
Any chance someone could answer Matt’s questions? I’m wondering the same thing. If you look at the Android platform, as a case study, they are methodically making it harder and harder to store things locally (SD cards), pushing you instead to cloud storage. Why is all talk of offline commits so ignorant of the branching capabilities of for instance SVN? Why do people assume that if you use SVN/CVS, that you never create branches? Branching != offline commits.
So true! The best metaphor for Git is that IT’S A LIKE A TOILET: IT STINKS, BUT YOU CAN’T LIVE WITHOUT IT (especially at the office).
When I realized that there is a bestseller book titled “Git for Humans” I realized that something was not quite right.
I mean … it’s commands! Some terms are borrowed from botany (trees, branches, pruning, etc), other from plumbing (porcelain, plumbing, etc.). So one gets confused by all these metaphors jumping from a gardner’s jargon to a plumber’s, and is left wonder WHY NOT JUST STICK TO COMPUTING JARGON? And all that pushing and pulling, and fetching … all very fatiguing.
Then … look at Fossil! A single binary file (and a small one too), and you even get a Wiki with every repository. With Git you can’t checkout two branches at once without having to clone the whole repo again in another folder … Fossil supports multiple checkouts in differente folders.
But Git is famous, and you’re force to use it. And there are people making a living out of selling courses (to computing firms, of course) on how to use Git — of course, good software wouldn’t need anthing more than a reference guide.
I think there’s a trend to masochism and payback in all this: first you feel that you are stupid because everyone else is using Git and you can’t get a grip on it after monthes of attempts, and then eventually you make it, and you feel like you’ve achieved some status of sorts, and it’s time to boast about it and make others feel belittled.
I have no shame in admitting that it took me over a year to get my way around Git, and now that I can finally manage to use without disasters I don’t feel I’ve achieved anything else rather than learning a dehumanizing tool. There is no “Git for Humans”, only humans willing to be Gitted (or –force gitted, I’d say) by giving up good taste, personal opinions, and serenity in name of the tiranny of the majority.
I don’t believe that anyone would willingly undergo the pains to learn Git if it wasn’t that it’s so widespread. The tiranny of the majority doesn’t prove anything about quality; and the fact that so many good develoers are using it doesn’t say anything about Git inherent quality except that it’s TRENDY. You only have to read history book to realize how intelligent people have embraced en masse stupid ideas and styles of live. Git is one of them.
I’m not blind to the fact that Git introduced some new concepts in version control. But such an hugly user interface, and a throughly inconsistent and horrible choice of commands name, along with unreadable documentation, are sufficient reasons for taking those good and innovative ideas and implement them from scratch in another tool (and I see Fossil as having fulfilled this).
I love GitHub! I hare Git.