That is an excellent point that I think deserves expanding.
I submit that files and directories ARE difficult concepts. Pretty much everything is difficult when you look into it enough.
I remember of the time they pointed the Hubble Telescope into a seemingly empty patch in the sky and with long exposure or something, we saw tens of thousands of galaxies from billions of years ago.
https://en.wikipedia.org/wiki/Hubble_Ultra-Deep_Field
Back to the subject at hand, I tried installing gentoo one time and it prompted me for something. I only vaguely remember the word "inode". Here is the first paragraph from the wikipedia from the article on inode:
The inode (index node) is a data structure in a Unix-style file system that describes a file-system object such as a file or a directory. Each inode stores the attributes and disk block locations of the object's data.[1] File-system object attributes may include metadata (times of last change,[2] access, modification), as well as owner and permission data.[3] Directories are lists of names assigned to inodes. A directory contains an entry for itself, its parent, and each of its children.
https://en.wikipedia.org/wiki/Inode
Files and directories may be an easy concept to understand if you have been exposed to them long enough (not sure how long is long enough) BECAUSE we have a good abstraction. I never had to learn what inodes are or how a filesystem works to use a computer. Can we accomplish something similar with version control?
* project
* project_20201213
* project_20201215
* project_20201219
but: most people also accept wihtout fuss, that it's OK that you make a phone call or email and just agree who throws their version out. Or that one user should simply lock the document for editing to prevent this from happening.
"Git for non technical users" (of single documents, not trees) seems pretty easy to build as a layer on top of git. 1) you use LFS and file locking. 2) You "check out" a file for editing which locks it exclusively 3) You completely hide the notion of "local repository" because zero nontechnical users, ever want to be bothered with distributed version control. Basically - you make a dumber but more robust verison of SVN on top of git-lfs.
Scheduling pulls daily/hourly and reserved checkouts a la Clearcase would probably suit them better.
*as long as the world is managing text files, which is, albeit not prohibitive, a big caveat.
There's also Fossil[1] which is stable and seems to have pretty good UX.
[0]: https://pijul.org