They and a great many of their colleagues can barely type without looking at the keyboard. You're suggesting that the kind of person who still double-clicks on hyperlinks can learn git?
I'm an aerospace engineer and I can barely use git. Git's UI/UX is a fucking disaster that just happens to suck less than what came before it.
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.
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.
Have you ever used Mercurial?
Surely it'd be cheaper in the long run to just spend the money on some UX designers?
What lawyers (specialists in their field) and others negotiating contracts could use is a subset of git, with better UI.
They need version control of the document.
They need to know who can edit it at this stage, or who needs to sign off (workflow management).
They need to know who did edit it.
Systems like this exist that are better than git, some people in the software industry use requirements tracking databases. These are almost literally what's needed once you (often included in them) add on the workflow management: collaborative document editing, ability to view diffs, knowledge of who edited it, restrictions on who may edit it and when, etc.
But if it's too small a field, or too disconnected from those of us who can make it, then software like this won't be made or widely used and they'll continue using the functional (but error-prone) method of copy/rename and email.
They need to learn a new document markup (how well does word play with git for grabbing diffs?).
They need to learn git/github.
It needs to be secure (these are legal contracts, potentially containing detailed information that doesn't need to be out when it's in draft and not signed). This is fine, host your own git repos, but that's an additional technical cost to the company.
It is, ultimately, still an ad hoc process. Is the cost of learning and adapting to this, to only gain the version controlled document store, sufficient to justify the process? Across an industry?