(As an aside, I sometimes feel the same way about node.js, where I've seen "node.js is awesome" listed among a project's "features." Nothing against it, I just don't get the obsession.)

I appreciate this comment with respect to Git right now. I've recently spent a lot of "hammock time" trying to come to grips with my views about this profession generally and what I believe is best going forward. One thing I feel strongly about is that while we are still maturing as a field, the pain points are unacceptable. There is still so much work to offload to the machine, requiring fundamental rethinking at many levels. So although I agree in principle with the initiative to help people "learn to code" (so that we can bring system design closer to the domain experts), I also believe that in the current state of things, it's a wasteful effort, since it requires conveyance of ideas that should be deprecated.

But even short of programming, version control alone would be useful in so many other fields. There's no reason why it shouldn't be a mainstream concept even for personal use (e.g., you're working on a thesis). Just an hour ago, during my annual flirtation with Git (I'm a Mercurial user), I wrote in my notes:

> the barrier to entry for new programmers is important. This would appear to weigh in favor of Mercurial — and yet, realistically, is a “layman,” i.e. someone who knows nothing about software development and has never used a CLI, really going to distinguish between these two systems, or will the very concepts of a VCS not prove to be the biggest hurdle?

I have used Git, and I think that for linear history the differences are not remarkable. But the attitude you refer to is crucial: do we want to hide complexity or expose it?

Incidentally, I have several Project Gutenberg epubs under version control for a personal project, and like the OP I attest that their work is first-rate. There's no comparison to any other digitizer in the public domain (that I know of).

> Every time a programmer has an issue with Git, whoever helps them has to sit down and explain the underlying system for 20 minutes and draw a bunch of sticks and bubbles.

This isn't true at all for a lot of people. I know a lot of people that just read the docs and are able to solve the issues. Others will Google the problem and find the solution on stack overflow. Everyone learns differently...

> Anytime someone shoe-horns it into a product they talk about how Git is so amazing and solves all these problems, but what they are really talking about is just a version control system, not Git specifically.

Git is amazing and does solve a lot of problems, but there are problems that aren't solved by Git. Even Linus himself says this here: (https://www.youtube.com/watch?v=4XpnKHJAok8).

Using the github API, rather than git, for creating epub books and pdfs is a great. Using git to control changes as the do is perfect as well.

> Non-programmers will never put up with this.

Ermm don't assume that everyone gives up right away. With the GUI interfaces we have today, Git is really simple once you learn it.

> Git is really simple once you learn it.

Pretty much everything is simple once you learn it. That's what learning is. But git certainly doesn't go out of its way to make that process easy.

>Pretty much everything is simple once you learn it.

I wouldn't say so. A lot of things are designed-by-committee implemented-by-the-lowest-bidder messes that are painful and complex even once you know how they work.

Git may have some weird design decisions but for the most part it's well-implemented and follows a simple conceptual model.

I can't think of a VCS with a better online tool than git and github. With editing books, it is entirely possible to use only the github editor, which effectively abstracts the git command line interface.

Git, in spite of the horrifically complex interface, is in essence a really dumb version control system (I mean that in a non-insulting way). This means it's fairly neutral about what kinds of data you can throw into version control. And more importantly, it almost never complains about what you give it.

I think that's why people are now starting to think about applying version control to domains outside of code and choosing Git to do it. For example, I had an idea a few years ago to make a CMS on top of Subversion as the data store (never got around to building it though). Now there are lots of projects like that built on top of Git: CMS, Wikis, you name it. Generally anything that can work off flat files is very easily converted to use Git as a back-end, giving you advanced version control features more or less for free.

From a practical perspective, the difference is not just that Git is a trendy new silver bullet, it's the "dumbness" that makes it actually easier to do that kind of work than it would be on older version control systems like SVN. Interestingly, for the most part, most of these projects do not really benefit from the distributed nature of Git (although for things like wikis and CMSs it can offer yet another feature: content migration between instances). It's more about the ease of use for getting data into a repository and under version control without it exploding when something unexpected happens, like a file getting renamed.

You might not get the best front-end experience for actually doing stuff with that version history (as other comments have noted wrt diff tools, etc., which tend to be geared towards code rather than other types of content) but that's the fault of those tools rather than Git (which is dumb enough not to care about content types), so it's just a question of incrementally building up a better toolset for your particular content domain. That's much easier to do and more approachable than building the whole infrastructure from scratch.

As for Github, it happens to have a nice interface, toolset, documentation and mindshare. Developers are familiar and comfortable with it, so there's no need to research and learn "yet another tool". And because it's cloud based, you can get up and running very quickly without worrying about hosting, etc. That's just more icing on the cake really.

Writing version control software is hard. There are just so many potential use cases, not to mention the differing perspectives on how users interact with each use case as well as how they're applied to specific projects a user is working on, increased complexity is inevitable. On balance, I think Git manages to strike a good balance with most things even with its unique eccentricities.

Git's popularity isn't because it's the best tool out there for all scenarios. It's popular because it's a distributed system that helped communities grow around code managed with it while removing barriers to entry. In my opinion, that more than anything will be Git's lasting legacy.

I have asked before, how many projects need a distributed version control system? It adds extra complexity to the concepts, and is probably rarely needed. (Distributed, not remote version control, which I can see as being useful).

You can't do anything that works offline without a distributed system.

You can use a distributed vcs as a centralized one if you want.

Save locally and push when you get online again.

> Every time a programmer has an issue with Git, whoever helps them has to sit down and explain the underlying system for 20 minutes and draw a bunch of sticks and bubbles. Non-programmers will never put up with this.

But from my experience, they have to do this exactly once per (non-stupid) programmer. The moment you grok underlying structure (basically all graphs and pointers), the apparent complexity disappears and most of the things in git become obvious. I see no problems with explaining this to non-programmers as well, you just have to spend a little more time, because they probably aren't used to think in terms of graphs.