I found the #1 reason to be incredibly ironic:

> The information model is complicated – and you need to know all of it. As a point of reference, consider Subversion: you have files, a working directory, a repository, versions, branches, and tags. That’s pretty much everything you need to know.

SVN's model is both simpler than stated here, but also much more complex to reason about. First of all, svn doesn't have branches or tags, it just has directories with cheap copy—tags and branches are just directories. The repository itself is also watered down pretty severely because the actual project directory is just nested in there somewhere with no formal locus. This idea of "everything is a directory" sounds simple, but in practice it's a architectural dead-end. The most obvious implication is that merging in svn will always be fraught with peril because a branch isn't a first-class citizen.

I used svn (and cvs before it) for much longer than git, and yet I never felt I had any clue what svn was doing under the hood, and the experiences I had over time instilled a fear of attempting to stray off the well-worn path of the most basic commands.

Although the learning curve was steep, and the CLI quite confusing, the git information model is actually much easier to grok because the primitives make more sense. After 6 months using git, I had a firmer grasp of the internals than I did after 10 years of cvs and svn. The idiosyncrasies of the UI don't really bother me because they are just superficial flaws that are easily memorized or looked up. The fact that I have the confidence to slice and dice commits to any history I can envision, with or without a network connection and remote repo, and do so with the reasonable confidence that I will never lose anything (reflog) make git the best VCS I can imagine.

Number 1-5 are mostly "I don't want to learn new things", so I'll ignore them. Do you remember when you learned source control for the first time? I don't, it was too long ago. Just like you have to learn SVN if you've never used source control before, you have to learn Git if you've never used distributed source control before.

* "Unsafe version control", and then gives examples using -f or +<refspec>, both of which advertise their destructive nature. Yes, you can also go in with SVN and obliterate history too, using svnadmin dump and svnadmin load. Git's reflog will have your back when you make mistakes, as long as the mistakes don't get too old.

* "Power for the maintainer, at the expense of the contributor" Yes, most people write code on one branch for a long period of time. Git does this just fine.

* "Burden of VCS maintainance pushed to contributors" First of all, nobody says that contributors have to merge. That is a decision that each project makes. Plenty of projects have the lead developers merging in everyone else's work. Second, the reason this is even an issue is because merging is such a pain in SVN that most people don't want to do it.

* "Git history is a bunch of lies" Again, this is up to the individual project. Some developers like to work on six different things at the same time, and then they go back and rewrite history so that their six changes end up as six commits. The difference with SVN, is that these same developers would simply avoid committing until they're done with all six changes. Some projects expect rebased patches, some prefer proper merges. Worse, the author says that "filtering" should solve this problem, but doesn't propose how such a filter would work.

* Complexity of simple tasks: Let's try not to artificially inflate the complexity of the Git tasks. For example, the Git examples assume no commit access, whereas the SVN examples assume direct commit access. If you don't have commit access to an SVN project, how do you do it? You either use git-svn and mail them a patch, or you use svn and mail them a patch.

A recurring complaint seems to be that "git add" is not the same as "svn add". I don't see why it would be. It's not the same as "ssh-add" or "useradd" either.

Have people done hallway usability testing on git?

i.e. just take a smart undergrad CS major and record their screen (& audio) while they try to figure out how to use it. I think this would definitely turn up some tasks within it that are way harder than they need to be. Do people really feel confident that learning git is a smooth process, not involving a lot of swearing?

The answer you mostly hear when complaining about programming tools is that you need to toughen up - yet startups are founded on the idea of not doing this to their clients. Making processes super easy for clients is a good thing, and we should gather information, find the common problem spots, and fix them for our own tools! We shouldn't just keep insisting that the customer (programmers) needs to toughen up and learn (as the default answer, anyway; some things really are hard)

Why isn't there user feedback tool for man pages, where it asks "Was this information helpful to you?" every time you use a man page? I bet the success rate would be pretty low.

In general why isn't there any information about which man pages are good and which are terrible? They just seem frozen in time. Compared to the analytics startups get about their customers, info about man pages is nonexistent. Yet there are probably ones out there which would be rated "useless" 99% of the time, and have been for 10+ years with no change.

Amen! I've felt like this for so long.

Ignoring the unnecessary parts about GitHub, he hits the nail right on the head with:

> Git doesn’t so much have a leaky abstraction as no abstraction. There is essentially no distinction between implementation detail and user interface. ...Its weakness is the complexity of simple tasks.

I swear, someone needs to invent a Git-wizard program. Interactive with a wizard-like interface, it will walk you through all the common kinds of tasks, even if they're fairly advanced, explaining all the ramifications along the way.

I haven't seen any programs like this -- all the GUI interfaces to git basically just translate to command-line commands, instead of trying to help you intelligently manage your workflow.

I don't think it would be easy to write a wizard interface like this -- it's a UI designer's worst nightmare -- but it would certainly help.

Git is far from perfect. But, there's roughly half bullshit, half "yes but is it really an issue?" things here to me.

Things like detailing the github process and blaming git just does not work for example.

Blaming additional git features that svn simply does not have.. is also nonsense to me.

Finally, you CAN rewrite history in svn, its just extremely painful. In git it's not and.. its a good thing. I prefer USEABLE history than trashy commits. And don't tell me its about having proper devs making commits. As pointed out, you get external commits in git. You can't control them without refusing them and then what? In svn you don't even have the possibility to refuse them.

Don't get me started on how svn is way more about the maintainer due to this...

Excellent article, this reflects much of my personal experience working with git in the last year.

Our whole department (>100 people) switched as part of a move towards decoupled development/continuous integration, we used perforce before. Luckily there were three people with excellent git knowledge who could answer all questions so this helped a lot.

However, I find myself relying on stackoverflow/google for some not-so-common small use cases where a glance at the manual just doesn't help (find all changes in local branch not in upstream branch x?). Also, the git commands and their options are sometimes not very logical as the article mentions (i.e. git show vs. git blame, the first needs the syntax "branch:file", the second "branch file", why? Small things like that take away from the beauty)

git is powerful and I prefer it to perforce for it's possibilities, but I think tools like mercurial are a better DVCS which just didn't have enough hype at the right time.

This generally sums up why I prefer Mercurial. It provides all the benefits of a distributed VCS, but with less of the complexity, at the expense of some (usually unneeded, at least for me) flexibility.

"If the power of Git is sophisticated branching and merging, then its weakness is the complexity of simple tasks."

The power of Git is its distributed nature and the fact that you can maintain local commits. When you have a single remote repository that everyone commits to, then sure, it's really easy to do things (have fun maintaining the ACL and merging any changes contributed by anyone outside the committer list via patch). If you think "it's really easy to branch" is the primary reason to use Git, you're using it wrong.

I think the biggest problem I have with git is that I don't understand how people can't get it. (That's assuming they understand DVCS, but don't get git. Not understanding DVCS is unsurprising.) It's like when my nonprogrammer friends who took CS101 didn't understand for loops. What?! It's just applying a concept you already understand.

It's unfortunate that git re-uses some verbs from cvs/svn with different meanings, but is that really such a big hurdle?

And I'm always surprised to hear complaints about git's user interface. I find the command-line interface far friendlier than others: auto-paging, colorized output, text hints of what I should do next, and fantastic tools (like bisect) in the same package.

And looking through my bash history, most of my commands don't use any options (the biggest exception is git commit). Possibly this is because I do most of my git interaction through vim-fugitive (and I have aliases for commonly-used complex commands). But I think it makes more sense to have a smaller set of commands that are logically organized (rebase mangles your history, reset re-aligns based on your history, ...) than a single command for every function.

Defenses of git sound remarkably like defenses of C++ syntax and feature design. In fact, I'd argue they are similarly written by people who are overly proud that they are smart enough to figure out some convoluted and arbitrary complexity, but not wise enough to realize that level complexity is unnecessary.

I'm all for trying to find ways to improve Git's learning curve, especially for non-technical users.

That said, if you're calling yourself an engineer, you've worked at a Git shop for over a month, and you're still complaining about how "hard" it is? I have absolutely zero sympathy. You're being paid twice the national average to do a job that's supposed to be mentally difficult. You use version control every day. Stop whining, learn to use your tools correctly, and stop subjecting the rest of us to your crappy, disorganized commits.

Ever try to commpile git statically?

Git makes you believe it's lots of small little utilities that work together.

Far from it. Git relies on Perl or another scripting language, not to mention it's reliance on curl.

You cannot run Git without these other sizeable programs.

I can make static binaries of RCS, CVS and SVN no problem. CVS uses SSH. No silly SSL and the certificate mess. I value the simplicity.

Mercurial (which seems to be a favourite among connoisseurs of versioning systems) relies on a Python intepreter, but it's reasonably contained to a single Python script; no installation required. You point Python at hg and it works.

Of course, it's been said that most of the time people who ramble on and on about these systems and their esoteric features do not need the advanced features. They rarely use them, except as points in a debate over which versioning system is "the best".

I love git and prefer it to svn, but he's right. It succeeds in power and usefulness, but utterly fails in the complexity department. Someday, someone who understands the virtue of simplicity and can control their "how dare you insult my favorite tool" response will take this criticism to heart and rework git (or at least, re-porcelain it).

Sounds like someone's just discovered how different DVCS are to centralized VCS.

Still, tools like Tower, Smartgit and Github for Windows, especially Tower, make interface to Git less painful.

With time, the interfaces to Git workflows can only improve, whereas what can you do with SVN?

That said, he may have a point about (branch &) merge message management in Git. Perhaps this can be improved closer to git with git extensions, e.g. implementing some sort of ranking and filtration system. Related to that is users should not really have to change the structure of the VCS itself just to filter messages.

I have to admit, it confuses the heck out of me. I am always in fear of destroying code because the documentation part is spot-on. I read and reread, and still feel like I am working on a best guess interpretation.

I can't count the number of times I've googled for simple commands like "how do I revert an uncommited file to its original state"?

    hg revert bla.txt
    git ???

I can say this: I've used both Mercurial and Git professionally, and for distributed version control, I found Mercurial much simpler to use.

My issue with git is the defaults. Generally the defaults and behaviour are geared towards large projects. It is absolutely correct in that sense - you don't want hundreds or thousands of contributors messing things up. An additional simple example is that push doesn't send tags.

But generally you want the opposite defaults for small projects/number of users. For example you do want tags pushed by default so every sees them. This places a large learning curve on the small scale projects and users. Remember that most users will be perpetual intermediates.

My analogy is that git is like a sharp knife. In the hands of an expert it can produce art, but in the hands of others we get blood. Some of the responses here are marvelling at the sharpness and what can be done with it, but are missing the point that others end up bloody!

I find his complaint about git's lack of abstraction strange. Yes, git's syntax could definitely be more consistent, but I can't think of how you could abstract away very much of git without quickly losing power.

On the other hand, one of the things I hated most about svn is that it doesn't abstract away the remote repository details at all. To do something as simple as check out a branch you have to type in the full absolute url to your repository, since a branch is basically a different folder higher up in the hierarchy. Talk about a leaky abstraction.

The abstraction between version control tools and the remote server(s) you back everything up on and the power of git's underlying model are both such big wins that I really can't get too worked up about the syntax.

Yet another anti-git rant which will merely bounce off the deflector shields of the git faithful. I doubt anything will change in terms of git usability and misfeatures until someone proves that there's a better way to do it by building an alternative that's all around better than git. But that raises the question of why one would continue to use git at that point.

Git is _awesome_. Once you "Get it", there really is no big problem. Sure you may have to look up some syntax occasionally and make an alias or two for your common uses, but really, it's no big deal.

And the benefits are compelling. Enjoy the amazing power of committing early, and committing often. Being able to revert to "10 minutes ago" is so freeing when trying out a refactoring idea. And being able to "uncommit" the last X commits to recommit them in a different order and with cleaned up messages and structure before sharing with colleagues... amazing.

All the quibbles about syntax really miss the point and the power of Git.

He mentions three ways to irrevocably lose data. Is that really accurate? I would think old refs are still present in the repo and accessible from .git/logs, but I don't have any experience actually collaborating with git.

Allow me to add one to the list:

11. Completely different concepts for the same commands as other SCM systems.

Case in point: Checkout. In every other system prior to git, going as far back as CVS in 1986, checkout meant grab a remote repo and copy it locally.

In git, it suddenly means to switch branches in a repo you already have. The real "checkout" was renamed to "clone".

Why not use something like "switch" instead?

That's nearly 20 years of muscle memory everyone needed to relearn because.. why?

Git add and SVN add do completely different things as well.

Was it simply not thought of that people who use git would be switching from another system at the time, very likely to be either svn or hg?

Dear OP,

If you're still using git from time to time and get frustrated please feel free to ping @gitdoctor on twitter. It's an account I run to try and help people use git right when they need that help.

Thanks and good luck!

You don't need github to make pull requests:

http://www.kernel.org/pub/software/scm/git/docs/git-request-...

Having used both git and hg, I very strongly agree. I learned hg first. Hg took less time to master than git took learn the basics of. The syntax of git is incredibly cumbersome in comparison -- I type a lot more. It's the standard, but relative to hg, not a very good standard.

git is only complicated because it lets you do everything you may possibly want to do, often a superset of what you actually want to do.

If you want svn-like commands, you can borrow someone's scripts or use a shiny GUI. I don't want svn-like commands because centralized version control is obnoxious.

Don't complain because it's hard. Programming is hard, math is hard, and if you know how languages, data structures, and algorithms work, git is actually pretty easy in comparison.

Git doesn't seem to have been developed with ease of use in mind. I've found that it's very powerful, and that most things that you want to do with it are possible, but not always as easy as it could be.

I'm working on a collaborative project with several inexperienced developers using various editors and operating systems, and dealing with line endings has been a serious time sink. The first step was "* text=auto" in a .gitattributes file to override everyone's local settings, as some had used custom settings when they installed Git.

Apparently the developers of Git decided to not support \r as a line ending, which ended up causing headaches for us because some legacy programs still use it. Several times, someone committed changes to a file where \r\n line endings had been replaced with just \r, for whatever reason. To Git, they had just deleted the entire file and replaced it with one long line. This frequently resulted in edit conflicts where it was very difficult to tell what had actually been changed.

The solution ended up being a filter:

    clean = LC_CTYPE=C awk '{printf(\"%s\\n\", $0)}' | LC_CTYPE=C tr '\\r' '\\n'

So, in the end it was possible, but the process could've been much friendlier.

I will say, though, that git bash is absolutely amazing and blows Cygwin out of the water for ease of use.

I'm going to be contrarian and say that he's mostly right for all of them. SVN was simpler, git is more complex. SVN did some things well that git does not so well.

But this all misses the point. Git is many many times more powerful than SVN. And that complexity is really useful, even for relatively small projects. You can learn Git's complexity, removing many of SVN's advantages. But you can never get Git's power into SVN.

I've been using git for several years on multiple projects with teams of various sizes (admittedly none larger than 10, though I avoid projects of that size for a multitude of reasons) and have loved it a lot. Especially compared to the merge headaches of svn. Or cvs. And mercurial just gets in my way more often than not. git stash I awesome

> The fundamental promise of any version control system is this: “Once you put your precious source code in here, it’s safe. You can make any changes you like, and you can always get it back. Git breaks this promise”.

Right there. I don't know who made this promise, but it's not what Git is supposed to preserve. Git is distributable is it not?

Number 10 is a total apples-to-oranges comparison. For an apples-to-apples comparison, the question is, do you want to give your contributors write access to your master repo? (and deal with the consequences)

If contributors have write access, then Git is almost as easy. There's just one more command ("git push") compared to SVN.

If contributors don't have write access, then there's no easy way to do this with SVN. Most places that I've seen will either have users submit .patch files via email, or put their changes in SVN branches (ugh). Or, they convince themselves that they'd rather just give contributors write access. Either way, Git has many handy ways to solve this problem (Github pull requests are just one of those ways), and it definitely wins on this front.

I tend to summarize it like this:

Git is built by people smarter than you for people smarter than you. Deal with it.

Now, seriously, Git is a) immensely flexible and b) born out of the needs of Linux kernel developers (or, more specifically, Linus' needs). I would expect it to be optimized for that case.

http://stackoverflow.com/questions/115983/how-do-i-add-an-em...

Git questions on SO with more than 300 upvotes should be considered bugs.

There are plenty of abstractions on top of git - most UI implementations abstract away the hard details, at the cost of not being able to understand what happens when something bad occurs because you never had to learn its intricacies prior. Seeing the consequences of such things it makes me appreciate git is left as raw interactions. Git is not for people that do not want to understand it. To me, it's similar to vim - its basic implementation is bare essentials and complicated concepts, but once mastered, far outweigh competitors who roll those concepts up into simpler ones and leave you with workflows on their terms.

> Power for the maintainer, at the expense of the contributor

Interestingly, SVN and Perforce are about power for the maintainer, with no benefit at all for the contributor. You can't even version control your own work with those tools.

Issue #10.

    alias commit='git add && git commit && git push'

git::mercurial vhs::betamax

I'll also say that tech folks don't like not being able to understand something, and enjoy understanding arcane things others don't (and once understood, no matter how hard it was to learn, it is suddenly "trivial"), further strengthening git's hold. I'm happy to see the author seems to understand git well enough to say, yes, I get it, and I still don't like it. I just wish he had talked about mercurial as the plausible user friendly alternative instead of svn, since svn is not distributed and therefor unsuitable for the use cases where git thrives.

Whoever designed Git was both a skilled programmer and a crappy designer.

I started dvcs with Darcs but it was too slow despite having a really really good CLI. Then I switched to Git because it was fast and within a week ran into so many sharp corners I had metaphorical blood all over my codebase. After a while I learned the useful subset of Git commands and life got easier with only an occasional sharp corner intruding every few months or so.

Then I discovered Mercurial. The speed was acceptable. The UI was intelligible. And I didn't hit any sharp corners. Life has been way way better ever since.

i had to work on a big corp job once they were using VSS5 in 2007. made me appreciate even CVS.

if you want to have a really simple way of working with git get the github for mac client. at the same time insanely inflexible.

but hey you know what in theory vss5 is quite "simple" as well. i mean how complex can a program be where distributed work is essentially happening by locking files.

I had hoped op would've said something interesting that might've led into 3rd generation DVCS, but this is definitely far from.

This sort of article sounds like s/unix/git/g of rants against UNIX/Linux command line & filesystem concepts that were common in the late 90's, as it was becoming clear that UNIX wasn't actually going to be killed by Windows NT, but rather was resurgent. Examples included:

- "Yuck, why such different terminology from DOS?" - "Commands are inconsistent and there are too many, where's my One Command or (better yet) One GUI that does everything they way I think about it?" - "Yuck, scripts that make things easier for my particular workflow, why didn't they just build it right the first time?"

Fundamentally it comes down to people who believe version control is a simple problem, and git confuses that for no good reason, or those who believe version control is an inherently complicated problem, and tends to require some study to understand the concepts. Git doesn't hand-hold, it exposes the core concepts at the data level, thus supporting any workflow for any size of team or work style. If you prefer a dictated workflow and task structure, there are plenty of wrappers that will help you - just don't be surprised if not every team agrees with your preferred workflow.

OP might have just professed "I am not technically advanced, Git has powerful features I'd never use, it should cater to me."

In general, there are too many of these articles on HN about "I don't know how to use it, so it's terrible."

What OP fails to grasp is the purposeful difference between Git and other revision/version control systems. Git attempts to cover anything you would ever want to do. Git is the Photoshop to SVN's Instagram.

You can use Git as if it were SVN, no problem. You can do Git commit-push-pull all day long as if you were SVN commit-update, and be none the wiser.

The one thing Photoshop has (as a similarly complex piece of software) that Git doesn't have is a single user interface. I don't see this as a problem. There are a bagillion Git GUI clients if you don't like the command line. Some are good, some aren't.

As far as having a good strategy for using Git on a real project. I think OP needs to spend some more time on Google. Here's a good article describing the most common workflow:

http://nvie.com/posts/a-successful-git-branching-model/

As a new DVCS user, I today just started playing with both using tutorials and books freely available on the web. I am using Mint 13 and the CLI. Of the two, the feel I get is that Mercurial is easier (more straightforward) of the two to use and Git is the more micromanage-able of the two. JMHO, but as a newcomer, it's my impression.

I especially liked the first comment about Subversion "anybody can write a simple VCS if they don’t have to make it distributed." It reminds me of my days working on a parallel compiler team. We always used to say, "we can get you answers very, very quickly if you don't mind whether they're correct or not."

Just as a parallel compiler developer must worry about recurrences and data dependencies breaking parallel programs, distributed version control adds a huge level of complexity which you cannot safely hide. However, I agree with the poster that the next major version of Git should clear up several inconsistencies.

(As a side note, some binaries labeled as ASCII in our Subversion repository back then caused massive corruption and shut down all development for days. Having too many assumptions made by your VCS and too few options specified by developers is bad simplicity!)

Subgit and Subhg are interesting.

http://rustyklophaus.com/articles/20100124-SubmodulesAndSubr...

Just use Mercurial for random private commits, send the Git people your changesets every so often:

    $ git init && git add . && git commit -m "Initial commit" && git remote add origin git@github.com:acct/repo.git && git push -u origin master
    $ subgit setup
    $ hg init

http://code.google.com/p/support/wiki/DVCSAnalysis

In Google's own words: "In terms of implementation effort, Mercurial has a clear advantage due to its efficient HTTP transport protocol.

In terms of features, Git is more powerful, but this tends to be offset by it being more complicated to use."

I really can't agree with point #1. Most of the things he lists as being part of the complex information model are equivalent and make perfect sense once you take a couple hours to understand how git works internally.

And no, that's not too much to ask for a tool that you will be using nearly every day. Once you understand git's data model and "patch-oriented" behaviour, you won't have to wonder about namespaces, the index, rebasing, cherry picking or fast-forward merges.

Point 5, or the fact that Git doesn't even try to hide its internal workings is actually why I prefer it over everything else. The UI can be weird at times since it evolved from just a collection of tools to operate on an on-disk, persistent and immutable data structure, but as far as being good at what it does, it's hard to beat Git.

Translation: “It’s easy, Granny. Just rev to 6000, dump the clutch, and use wheel spin to get round the first corner. Up to third, then trail brake onto the freeway, late apexing but watch the marbles on the inside. Hard up to fifth, then handbrake turn to make the exit.”

Haha!

undefined

I felt the article had some fair complaints. The problem is that the author felt that going back SVN was the resolution to those complaints which I found ridiculous.

My question is how does mercurial compare to git on all of the author's points?

The issue with git is that's got all this cruft built around it, but for the most part it's very rare you need to jump into it in that level. I've been using git for about 2 years and only needed to rebase for the first time very recently.

There are issues, and flaming the author saying he needs to read more is disrespectful (and ignorant of the issues), but git is a community, open source project. Not happy with the existing docs? Rewrite them, call it git for humans and off you go. I've seen projects doing work to 'nice' the command structure, so there's other people attempting it.

But we can all agree git reset is weird.

I have used subversion heavily. So many things are not at possible with SVN. But, it can be done in Git easily. Of-course, it requires learning and a bit of change in the mind-set. But, it is worth it.

I hate blogs that put pop-ups over part of the content with no way to close them (I'm not subscribing to your mail list or following you).

I don't hate Git but I do agree with many of your points. There's ccomplexity that should be hidden (or more hidden) and there's inconsistencies that still catch me occasionally. I've never actually lost code on Git though it's taken me a while to find my code.

It's also not fair to confuse Github's "Pull request", "Fork" and "Merge" with Git. These are still just branches and merges.

1. Not sure his issue here - I count 9 things you need to know for Github (one of which I have never needed to know - treeishes), and 7 things for SVN. It's really not that complex.

2. The command line syntax:

But the shortcut for “git branch” combined with “git checkout”? “git checkout -b”

Indeed. You can branch your code, but not check out the files from the index into the working tree.

Perhaps the confusion here is because the author is coming from an SVN background, where checkout means something different.

As for git am being obscure - sure, seems a little, but then there are two things: 1. don't use it if you don't need it, and 2. for kernel development, this is remarkably useful!

3. Documentation: completely invalid. The man pages might seem a little terse, but then if you are looking up a command and you don't understand the terminology, then you should probably consider typing in

  man gittutorial 

Alternatively, if you are trying to understand how to use git (and it might be worthwhile for the author to follow this advise) then try reading the git user's manual, which can be found here:

http://www.kernel.org/pub/software/scm/git/docs/user-manual....

Hint:

git rebase is explained here: http://www.kernel.org/pub/software/scm/git/docs/user-manual....

To understand how git checkout works, read here: http://www.kernel.org/pub/software/scm/git/docs/user-manual....

4. Information sprawl: actually, I consider myself to be a git newbie (mainly use github!) and frankly I've not needed to learn that much about git so far. However, whenever I've come up against something new, I've checked the documentation and after about 5-10 minutes I've understood the concept needed to get me going. I don't consider myself to be an expert in git in any way. However, as someone who has to program, I tend to find that for any system with enough power, I have to learn new things regularly. git is one of those things. Learn to love it :-)

5. Leaky abstraction: first, don't make the title "leaky abstraction" if you don't believe that there is any abstraction in the first place.

Secondly, it looks to me like they are trying to take your branch and insert it into another repository? Can't quite tell what is required here... certainly I'd love to see the way that this would be done in SVN!

6. Power for the maintainer, not the user...

??? I'm sorry, but the author is complaining that git is powerful, and works really well in highly distributed systems where you have a lot of parallel commits? Well, uh... duh?

The complaint here is that it's not usable for "ordinary" repository users. I would consider myself a fairly ordinary user, and I can honestly say that I don't consider that git is that hard to use.

7. Unsafe version control

DON'T DO THOSE THINGS!

8. In the traditional open source project, only one person had to deal with the complexities of branches and merges: the maintainer. Everyone else only had to update, commit, update, commit, update, commit…

Which meant a massive bottleneck when doing branching and merging. That's the whole point of git - it's version control done large. Or otherwise known as "distributed version control". I'd recommend the author read up on some of the advantages here: http://git-scm.com/about

9. I don't really have much of an opinion on this.

10. Github != git. For the record, I love github and I really don't find it that hard to use, or anything so complex that I can't do it fairly quickly.

This is a pretty decent criticism of git's current UI. The good news is that the core primitive operations underlying git are fine, and all that needs to be done is to create a better UI out of them. There's definitely room to build a great, user-friendly (commandline) user interface for git. I'd bet that the existing high-level operations like "push" and "pop" were relatively late additions.

undefined

Yet another "i hate <this>" article :-)

While I agree with the article in many of its finer points, the hyperbole ruins its effectiveness. For example, I don't find it frequently necessary to "log on to github and issue a pull request" to commit changes. Additionally, github != git, blaming one for the sins of the other just muddles things further.

Point 10 is not a fair comparison, since the svn example does not cover passing around patch files and trying to keep multiple svn repos in sync.

How can this article complain about syntax and documentation, but leave out a discussion of submodules. As much as I like git, that's really the worst part.

What I hate about git is the religious fervor surrounding it. It's a tool. And energy spent debating the good or bad of any tool could be better spent building something amazing.

There's a lot of unfair or simply untrue comparisons in that post.

Interesting point of view but it please try to learn your tools better next time you write an article :) And try not be a hater, it only harms you and not doing any good.

thanks for a nice list. i also dislike git for many of the same reasons. i think it's crap based on those reasons, and i'm saddened it's taken off.

I like GIT. If the man pages were improved to be more human readable then I think a majority of all these "i hate git" articles will go away.

This is why the big boys still use Perforce.

Another crybaby blog post by someone that wishes it were still 1997.

If git syntax is that hard, then programming might not be the correct vocation.

Back to SVN via email, and flash drives! I'm so glad my last day is Monday.

It would only take a week to properly learn git. Most people spend a lot more time to learn a programming language or an operating system.

I consider git to be almost like a programming language.

The information model is not complex, it's actually quite simple if you really understand it.

* blob: roughly a file (without a name)

* tree: roughly a dir (maps names to blobs and trees)

* commit: tree + parent commit(s) + meta data (author, commit msg, etc).

If you grok this core data model, a lot of things will make much more sense.

http://git-scm.com/book/en/Git-Internals-Git-Objects

I don't know if anyone shares my experience, but I actually found svn rather mysterious and difficult to understand. I never actually saw the point to it at all, so I never bothered using it (unless it was mandated by some authority).

It's only when I understood git that I really understood what version control is supposed to be about.

So, I think people who try to "dumb it down" by giving tutorials that ignore the data model and focus only on the usage are not doing anyone a favor.

Git should be treated like a new programming language or a new operating system. Spend a few days reading (or watching youtube videos) about how it works and why it was designed this way.

Yes, you really have to understand how it works. But it's precisely the fact that you can do so, that make git the best version control system out there in my opinion.

git definitely has room to improve on the usability, it's overly complicated. git is "popular" not because it is the best, but because linux defaults to it.