You forgot "brilliant".

He knows a lot about his domain, sure, but he's no god and there are a lot of areas he knows diddley-squat about.... user interface design for one!

And Einstein knew nothing about biology.

I'm sure he knows "diddley-squat" about most areas, but as long as he knows a lot about his domain then he's an expert.

And he is good at user interface design, and git is a good example of that; it's just not aimed at beginners. It was designed by and for expert users, and the interface fits that very well.

admittedly "expert" UIs are different from "noob" UIs, but the number of "git magic spell" followers out there mean that it isn't a good UI for the majority of people who use git.

Git being operable with a pry bar and repairable with a hammer is a good proof that in this context it's a good design.

The learning curve to git is not great but as far as I know nobody has publicly released an option that's improved enough over git to motivate the cost of switching technology. If it's not working for you the only advice I can give is either learn it until it is actually working for you rather than being in the way or try to find a better workflow.

Edit: also in a Windows environment, svn copes slightly better than git. First project we tried it on had the worst possible environment, a mix of Windows and Linux systems. Line ending nightmares everywhere.

It also took a while to work out how to kill (with fast-forward) the spurious "merge commit" you get every time someone does a pull. You don't have that with svn, you just do the merging locally when you update and it doesn't generate a commit.

For me Git was really a much needed upgrade to subversion. Working with branches (testing and production, we even have some repositories with multiple testing and production branches) are working like they are supposed to do. Changing commits (oops - I forgot to add one file) before pushing them to the repository for the other users is another big advantage. Working on multiple features in parallel - I couldn't do that with Subversion.

We've nearly completely eliminated the "handcrafted" local copies with multiple half finished features since changing to Git.

And if you want to use Git as a Subversion alternative you can use it in this mode too - altough you are missing out on some good new features.

I don't want to change back to Subversion.

The only disadvantage is that SourceTree (the GUI tool we are using) is a pretty lame duck in Windows. But the command line is excellent.

branches are branches in svn or git... your process may not have been correct, but lets not blame the tools here..

modifying commits is a big no-no for me, so thats not a drawback at all, the fact that its not possible in svn is a win for svn.

For one of our biggest projects branches in SVN didn't work at all.

We have multiple production, test and development branches and merge branches (features) from one branch to the other (development -> testing -> production). Sometimes we cherry pick a single commit to another branch.

In those days SVN wasn't so flexibel with branches as we wanted to (or we didn't understand it enough), so our workflow was much more rigid.

I used SVN for 7 or 8 years and then Git for the past 3, with about a year of overlap (on different repos).

To me, Git is vastly superior. I tend to use it in quite an "SVN-like" fashion - there's a single main trunk branch that we all share - but in terms of what I can do locally it blows SVN out of the water.

The difference is that Git makes things that are hard or impossible in SVN trivial. So for e.g. I create local branches all the time; I commit a bunch of small changes locally as I experiment with a fix, and then `merge --squash` to leave a clean history for others; merging fixes across different branches is easy and just works.

Most people just spout the same sheep-like line "git>svn" without being able to justify it!

The SVN UI is just horrid in other dimensions, mainly the "you can't do that at all" one.

(getting down-voted for it, but someone has to say it)

tags should not be committed to... end-of-story.

as for 'svn-log not showing commits'... I've never heard of that one in the last decade of using it... I'm genuinely interested in how that came about.

We see that a lot of companies(our clients/users) adopting Mercurial, you just don't hear about it. Often those are companies with employees that don't tweet or post to HN ;)

RhodeCode is used also in around 60 universities, and we learned that in a lot of them they teach Mercurial as well as Git.

For a large company it's actually much cheaper to adapt Mercurial as they new DVCS because of learning curve.

I hope companies like Facebook and Mozilla will make soon Mercurial very very fast. There's constant work on it coming from those companies to improve it.

I don't know any of the other distributed version control systems. The only other version control system I have much (too much) experience with is Subversion and it can't hold a candle against Git.

In my opinion Git is the C language of version control systems. If you are careless it's not the tool for you. Otherwise you have a really great tool with lots of power.

In an ideal world -- one where network effects of GitHub hadn't crushed all competition -- I'd get to choose Mercurial as my daily version-control system. It has similarities to git, in that both are largely user interfaces to a DAG, but its guiding philosophy and approach to the interface it exposes are far better in my opinion.

In my opinion Git is the C language of version control systems. If you are careless it's not the tool for you.

You probably don't want to make that assertion; we now have close to half a century of evidence that no human currently living can use C safely, and I don't think you'd want that to carry over to git. And it's not a matter of "careless" or not -- extremely intelligent, extremely-well-trained, extremely-careful people still write unsafe C.

You're right that C is the wrong tool for a lot of applications. But if you need total control and speed and power it still works for many projects.

Be that as it may, it's a common misconception that the more popular tool is always the better tool. There are a lot of factors to a tool's success and the technical ones are generally far less important than most people think.

Brushing aside some relatively minor differences, Mercurial is very similar to Git, except that it was designed by people that don't have an all-consuming disdain for all of humankind.

Not saying I disagree... but subversion is still king in the corporate-engineering companies and it tends to work well in those types of setups.

Just beware of having unjustified-opinions. SVN may not be trendy... but neither will git in a few years time.

BTW: Mercurial still beats them all.

For some values of "work". We're using SVN at my new job, with a single trunk branch. Not having the ability to commit locally, and mess around with local branches is a pain in the ass. I found a solution though. I cloned SVN repo using git-svn and now I can make local commits like a pro, and use my beloved magit (Emacs git interface).

(I used git in an cvs-to-svn migration, and stayed since.)

I know that many people don't like it, but I can fix up commits in my local repository and push the change upstream in one.

With SVN I wasn't able to do this, so it was a big pain if you had to fix a bug if you were in the middle of a big feature, or if you had an experimental feature you wanted to clean up and release a month later.

  > just happened to win the PR battle against its superior foes, because...Idunno, Linux, I guess?

The Git DAG and its content-addressable file system are an elegant solution to the problem of distributed version control. The implementation is clean and dead-simple, yet immensely powerful. This is the basis of good engineering.

> an even worse UX

Git was designed to expose its underlying implementation and not to isolate the user from it. Unlike other systems, its subcommands give the user the ability to manipulate the underlying data structure directly.

That doesn't mean it has a bad UX. Just that it has the UX of a power tool.

I also think that Git played a big role in the growth and popularity of command-line tools over the past decade. And that its interface inspired the subcommand pattern that is now commonplace in docker, vagrant, and others.

I think besides a PR battle (there's PR people for RCS'es??) I think Git won out because "the server was free". Competitors at the time needed a big (if there were large numbers of committers) server that someone had to pay for. By that I mean the hardware to host the server -- Git needs either none, or a very lightweight machine for a server.

Chalk that up to the power of fashion. Otherwise, people would use an SCM that doesn't destroy their work in the blink of an eye and actually has an API that deserves the name.

And (c) lose the entire subtree the repo is in.