I mean, i just find any defense of Git's "simplicity" hilariously unobservant. I'm sure to many Git is perfectly simplistic in design and UX. It is clear, and well thought out.

But, for many others, Git is a confusing mess. And, i should think, nearly everyone has heard someone(s) call Git confusing. I don't think it is up for debate that Git is known for being confusing.

Who cares if it "is" confusing or not - that's relative. Most things aren't confusing if you've learned the subject matter.. right? It is known for being confusing though, and that is clearly to people who don't know Git. Ffs, there wouldn't be debates about Git's UX every month on HN if it was so utterly non-confusing, haha.

Some things are very simple and easy to learn, use, and adopt. Git is not one of them, clearly and objectively.

One thing often missing from the debate is this: version control is a fundamentally complex problem. In my view, it's a unfair to blame this complexity on the tools. The cockpit of an airplane is famously complex not because Boeing and Airbus wanted it that way but because flying a plane is complex, and because they couldn't make it any simpler.

Git has a fundamentally sound architecture, and with a correct mental model of what's going on you'll be able to deal with pretty much any situation. Nevertheless, you won't get beyond the simple use cases if your conceptual picture is incorrect, but that'll be the case for any VCS. I don't believe that git is necessarily superior to mercurial or take-your-pick, but let's not disregard that we're dealing with something difficult.

Version control is complicated, but git adds a whole nother layer of bullshit on top of it. Why do you use checkout to change a branch, create a branch and revert a file? Not because version control is hard, but because as a CLI, git does many things wrong (example from http://stevelosh.com/blog/2013/04/git-koans/).

> Why do you use checkout to change a branch, create a branch and revert a file

git checkout lets you check out files from a particular point in time. If you don't specify a path, it will check out every file. If you don't specify a point in time, it defaults to HEAD (like every git command). I fail to see what is confusing about that. You're not "reverting" changes to a file, you're just checking out a version of the file from the history.

`git checkout -b` is shorthand, and is shorthand that I personally don't use.

> One thing often missing from the debate is this: version control is a fundamentally complex problem.

No, it's not!

I've been teaching SVN to Electronics Engineers, Designers and other folks who have never used version control before. It's always been very straightforward. They'd be able to use it effectively after a quick tutorial and demo, with a few notes of advice.

I've been teaching Git recently... until I gave up. It's a giant WTF clusterfuck. Git is the ultimate failure in simplicity and user experience.

Just use SVN (it works on git repo).

> No, it's not!

Yes it is. SVN is so "simple" because it doesn't have many of the features needed by large teams working on code. It's simply not fit for purpose.

> Just use SVN (it works on git repo).

Unless you need branches (and merge them), code that doesn't get silently corrupted, a proper history of all changes, the ability to work offline without connecting to a server. Y'know, the problems that git was built to solve.

> Unless you need branches (and merge them),

I use svn to merge branches every day. I do agree that git is probably more useful for more complicated setups, but svn is very capable of branching and merging.

> I use svn to merge branches every day.

Has it gotten any better with conflicts? From what I heard a few years ago, it's still absolutely shocking (if two people touch the same file you can forget about merging your branch).

I typically don't have any issues, but I guess that would heavily depend on your workflow.

My problem with Subversion is that it only really works well for trivial cases where you have linear and non-overlapping changes. It's great for configuration management, but not much else.

If you have more than 1 person doing simultaneous changes to a repository which might overlap, SVN becomes a pain to use because its merge handling is basically "Oh, there's a conflict. Here is the whole mess, good luck!" and you lose access to all the tools SVN provides for normal use.

Git (and hg) treat merges as an everyday thing, and a merge conflict does not leave you unable to do basic things such as commit or stage changes with the index, which is a huge help when resolving large conflicts.

I've met people who have given up entirely on merging SVN branches. They just copy changes around manually. Coming from git, I thought their overly-cautious usage of svn was ridiculous. My attitude changed when I ran into revprop issues merging my changes and struggled to discover why some commits seem to randomly be missing svn:mergeinfo. I only had so much time to deal with the issue, so eventually I gave up on fixing the problem and just generated patches to apply manually to the other branch.

One thing I always worried about when experimenting with commands in SVN was that I'd permanently screw up the server. With git, I was comfortable in the knowledge that as long as I didn't push, at worst I would screw up my local repository. Even better, I could just make a copy of that local repository before trying something I wasn't sure about. I haven't had to do that in a very long time, but it was nice while I was learning.

git is not the first version control I tried, but it's definitely the first that really made sense to me. Sure, there's a bunch of badly named commands to memorize, but the underlying concepts they represent are simple.

Personally, I find darcs lovely to use. It avoids complexities like branches (you already have a filesystem - if you want to work on multiple things, you can have multiple checkouts) and provides a simple UI that shows you what you're doing every step of the way by default.

Try Mercurial. It's mental model maps more directly to SVN.

I have successfully taught it to people like CEO's and CTO's with very little difficulty.

The problem with Git is that it has 3 areas of state (working-index-repo) instead of 2 (working-repo).

That makes things HORRIBLY complicated for the 99% of useful use cases.

+ there are nice tools like RhodeCode to work with Mercurial repositories.

Git is not "simple" from the point of view of new users. But it is "simple" from the point of view of the programmers of Git. There's the graph structure and some tools to manipulate it. It doesn't do much to hide that.

The underlying code of the application I'm writing would be much "simpler" if I didn't have to add all kinds of features to make it easier for the user.

Also, Git is not so much a VCS application as a framework for version control.

> "from here we can state that, obviously..." He suddenly stops, slowly turns the head down, keeps mumbling "so we can obviously...". He slowly walks in the room, trying to catch the thought, then leaves the room... Some minutes pass. Then he comes back, with head up, widely open eyes and confidently continues - "Yes, this is completely obvious - so from here we can easily get the following conclusion."

I had a lecturer who did this! With the only difference being he didn't leave the room, he would just stand there speechless with a poker face and then - 0.5-1 minute later - he'd say "well, this is obvious".

SUDDENLY, during the exams he expected us to explain the obvious.

There is a good complementary story to this, of the math professor who is asked how to solve a math problem by a student. The professor pauses, then says the answer. The student asks again, "But how do you solve it?" The professor pauses again, says the answer again. When the student protests, the professor says, "I already solved it two different ways! What more do you want?"