If you want to use Git as a backend for non-(software-)technical users, you really need a different UI on top of it. It sounds like fairly simple “upload new file version with drag-and-drop” options would already help a lot here.
The biggest one is that Git is really difficult to use. If you think otherwise, you probably don’t understand it very well.
No, git is deep and has a long and sometimes steep learning curve, but if you do understand it very well then it is not difficult to use.
People make it look difficult to use by lacking the knowledge required to use it.
I honestly think most people shouldn’t be using git, a simpler VCS with an easier learning curve is what I would rather see people use. Silly jokes like XKCD #1597 are a symptom of people who are not interested in learning git being forced to use git in situations where (due to the fact that nobody seems to know git) it clearly is overkill and isn’t being used even close to its full potential.
And to respond to the referenced claim of: “Git is not a success story. Git is a failure as a system with a crap user experience that forces you to learn more about the tool you’re using that about getting your work done.”
Git is successful for the people who made it to manage the task they needed it to manage. The UI could do with some improvement, but its complexity is mostly necessary for the task it’s for. It’s not “a failure” just because it’s over-complicated for your workflow and just because you don’t need most of the features it provides. Just like vim would not be a failure if someone insisted on replacing windows notepad.exe with it and then everyone who was previously happy with the simple and limited feature-set of notepad.exe started complaining.
The real failure is in all the people who popularized git as a solution for all the 99% of use-cases where it’s extremely overkill or just mismatched.
I agree about Git being easy to use if you understand it well.
That’s exactly why they’re saying it’s a failure: the deep knowledge is necessary. Good tools don’t require understanding their inner workings to be used efficiently.
You can see that as failure of UX or of abstraction, but a tool’s value is not dissociable from that UX so such a failure is a failure of the tool.
TL;DR: you and I both have Stockholm syndrome* and enjoy using Git, but it’s not a tool design success.
* the actual existence of the phenomenon is disputed, but you get what I mean
I think this would benefit from visual editing/diffing and probably something like a CRDT instead of git but getting that off the ground may be a fairly big lift.
My personal suspicion is that, in twenty-five years, using version control will be considered a basic life-skill for all employed people. Just like we’re now expected to know how to operate our own elevators, pump our own gas, scan our own groceries, and type our own e-mails, a kindergarten teacher in 2050 will be expected to write their own commits of updates to grades.
I expect someone will comment on how dystopian that idea is and I’m not necessarily disagreeing. It just feels like it is in that sweet spot of being useful enough for businesses to demand it and there are enough people who can muddle through for the mandate to come down. Suddenly, knowing git (or hopefully something better that comes along) will be your problem.
I doubt it, at least in a general sense. Many more systems will gain change tracking and history features, sure, but not in the sense of a single widespread VCS.
If you want to use Git as a backend for non-(software-)technical users, you really need a different UI on top of it. It sounds like fairly simple “upload new file version with drag-and-drop” options would already help a lot here.
No, git is deep and has a long and sometimes steep learning curve, but if you do understand it very well then it is not difficult to use.
People make it look difficult to use by lacking the knowledge required to use it.
I honestly think most people shouldn’t be using git, a simpler VCS with an easier learning curve is what I would rather see people use. Silly jokes like XKCD #1597 are a symptom of people who are not interested in learning git being forced to use git in situations where (due to the fact that nobody seems to know git) it clearly is overkill and isn’t being used even close to its full potential.
And to respond to the referenced claim of: “Git is not a success story. Git is a failure as a system with a crap user experience that forces you to learn more about the tool you’re using that about getting your work done.”
Git is successful for the people who made it to manage the task they needed it to manage. The UI could do with some improvement, but its complexity is mostly necessary for the task it’s for. It’s not “a failure” just because it’s over-complicated for your workflow and just because you don’t need most of the features it provides. Just like vim would not be a failure if someone insisted on replacing windows notepad.exe with it and then everyone who was previously happy with the simple and limited feature-set of notepad.exe started complaining.
The real failure is in all the people who popularized git as a solution for all the 99% of use-cases where it’s extremely overkill or just mismatched.
I agree about Git being easy to use if you understand it well.
That’s exactly why they’re saying it’s a failure: the deep knowledge is necessary. Good tools don’t require understanding their inner workings to be used efficiently.
You can see that as failure of UX or of abstraction, but a tool’s value is not dissociable from that UX so such a failure is a failure of the tool.
TL;DR: you and I both have Stockholm syndrome* and enjoy using Git, but it’s not a tool design success.
* the actual existence of the phenomenon is disputed, but you get what I mean
Agreed. Git is the first version control system I’ve used that mostly just works and has all the features I need. (And yes I’ve used mercurial).
Which I guess is why we’re currently entering a phase of many tools built on top of git.
I think this would benefit from visual editing/diffing and probably something like a CRDT instead of git but getting that off the ground may be a fairly big lift.
My personal suspicion is that, in twenty-five years, using version control will be considered a basic life-skill for all employed people. Just like we’re now expected to know how to operate our own elevators, pump our own gas, scan our own groceries, and type our own e-mails, a kindergarten teacher in 2050 will be expected to write their own commits of updates to grades.
I expect someone will comment on how dystopian that idea is and I’m not necessarily disagreeing. It just feels like it is in that sweet spot of being useful enough for businesses to demand it and there are enough people who can muddle through for the mandate to come down. Suddenly, knowing git (or hopefully something better that comes along) will be your problem.
I doubt it, at least in a general sense. Many more systems will gain change tracking and history features, sure, but not in the sense of a single widespread VCS.