Anyone doing contracts, requirements documents, writing/editing cycles could use something like this with varying additional capabilities.
With no change to philosophy (still staying on the user side), a system could be made based off the principles of existing software.
You need some workflow management software + a document store. The document store needs to provide rich text editing, and the ability to edit only specific sections in parallel. "section" is a customizable unit depending on the type of contract. Could be paragraphs, or larger logical units. Part of the workflow management is kicking the contract back and forth between you and your collaborators and the other stakeholders. At various stages it's editable by different people, some stages are just for review (not edit), finally various sign-off stages.
It's pretty typical of requirements document databases. You'd need it exposable to third parties outside your company, and you'd also need confidence in privacy and security. Neither are trivial, but neither are impossible.
The software for your needs literally exists, but isn't marketed to you. It's too costly for smaller offices (both licensing costs and management costs), and would require a good sales pitch because, well, people don't like change.
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?