Git is not great UX wise, but it's probably not as big of an issue as people like to make out, especially if you are already comfortable in a shell. The reason people find git hard is that concepts of distributed version control are hard.

There are plenty of nice git native GUI's and web apps, and mercurial offers a more consistent command line UX, but that doesn't change the fact that people need to understand a crap load of higher-level concepts before they can find their DVCS useful. Such as:

file-system folder structures

diffs/patches

commits/uncommited changes

branching

merging and conflict resolution.

remote vs local repositories

To me it's like how people complain about mathematical notation being complicated and inconsistent, but that's just the first superficial "alien" looking stuff that tells you that you don't understand the new concept. Once you understand the underlying concepts, the notation doesn't get much further thought.

>The reason people find git hard is that concepts of distributed version control are hard.

Maybe. For me it was because the documentation is written like a comp sci whitepaper. I've ranted about this elsewhere on HN but the man pages are filled with stuff like "update remote refs" as if a person would have a fucking clue what a ref is and why you'd want to update a remote one.

Branching, merging, tagging, all of that sounds great. I've been using git for years, but the problem is that I don't use it every day, and so I still get a little wary when I want to run a merge. I can't tell you right now off the top of my head how to merge if there is a conflict. I always have to google around for "how to undo a commit". Etc. etc. etc.

Where the fuck do my files go when I switch to a different branch? Do they actually change in the working directory? Checkout vs fetch? Where exactly in the file system is this alleged "staging area"? I have no idea about any of these, mostly because the documentation is just so poorly written that it takes me too long to find out the answers and I have more important things to do than Greco-Roman wrestling matches with my software tooling, but I'm afraid that if I just try things at random I'll do something I can't undo because none of the options seem particularly intuitive.

It's just not a very good piece of software.

Software is good , your mental model of it is bad. Trying to put the squre peg of git into the round hole of filesystem is bound to produce frustration.

> The reason people find git hard is that concepts of distributed version control are hard.

Have you ever used Mercurial?

I think you would want to combine an open source toolset with a paid service with trained monkeys to bridge the gap. For instance let's say I send a draft out, and receive a PDF markup back. The trained monkey would make sure that the new version is accurately reflected in the repo. As long as I am working natively, then exporting my response back into whatever lame format is desired will be trivial. It's a bridge to a better world and more elegant system.

The engineer in me hates how inefficient that is. Also it smacks of a make-work project... paying someone to manually insert markup seems like a huge waste of money.

Surely it'd be cheaper in the long run to just spend the money on some UX designers?

I think you need a human to manage the import bc any OCR or conversion error could kill the whole experience. Hopefully rhe machines could get us 90 percent of the way there. You know law firms used to employ armies of typists to prepare manual (pencil) difs of paper docs, so there is a certain cultural willingness to pay for perfect results, particularly on larger transactions.