[srich36]

Git is what happens when a technology is born out of hardcore engineering. Most of the world could greatly benefit from its functionality but it’s too hard for non software-engineers to learn. I hope the next era of version control thinks about the problem from a less technically inclined user’s perspective. Out of curiosity, does anyone know of any good alternatives that make version control easy? I personally love git, but want to see it’s benefits brought to a wider base of people. Projects like Bit are a step in the right direction.

[waynesonfire]

I disagree. "Most of the world" has a hard time understanding hierarchical structure like files and directories. Once you introduce git, which basically adds a time dimension to that hierarchical structure--good luck understanding that. It doesn't matter how user-friendly the tool is if the fundamental concepts cannot be understood.

[minot]

> "Most of the world" has a hard time understanding hierarchical structure like files and directories.

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?

[mbirth]

I wouldn't say so. From watching non-dev people, I can say that they DO know about files/folders and they can very much add the time dimension to them. It just looks a bit different:

* project

* project_20201213

* project_20201215

* project_20201219

[geraldcombs]

People seem to be able to use Time Machine, which adds a time dimension to macOS' hierarchical file structure, just fine.

[eveningsteps]

lazygit was one of the greatest discoveries for me (just see their example workflow in GIF!): https://github.com/jesseduffield/lazygit

[alkonaut]

Any user who deals with a set of files that need to be coherent, such as a source tree, I'd argue is already most likely technical. Non-technical users are used to having the time dimension, but for individual documents. They understand the notion of revision A and revision B of a document. Most people also most likely understand that if two people edit revision A, they would create separate, conflicting revisions B.

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.

[TravelPiglet]

Working with graphics people and their assets I can promise you that the idea of conflicts are completely foreign to them.

Scheduling pulls daily/hourly and reserved checkouts a la Clearcase would probably suit them better.

[Spivak]

Huh? There’s version control for designers. The leader in the space is called Abstract.

[shakow]

> Most of the world could greatly benefit from its functionality

*as long as the world is managing text files, which is, albeit not prohibitive, a big caveat.

[RupertEisenhart]

Even just using text files surely? Even a single document can benefit from git-- or are you thinking that tree-history and other things which are sometimes provided by editors are enough?

[Quekid5]

If you can live with non-Git then Pijul[0] seems quite promising both in terms of UX, but also power relative to git. (It's probably still quite rough around the edges right now, though, it's 1.0.0-alpha).

There's also Fossil[1] which is stable and seems to have pretty good UX.

[0] https://pijul.org/ [1] https://fossil-scm.org

[Igelau]

Unfortunately git is the easy one, but you're right about the accessibility. I headed a transition from svn to git once, and even though I think git is conceptually simpler overall, it quickly became apparent who paid attention to the graph theory portions of Discrete Math and who didn't.

[ibraheemdev]

Pijul [0] also claims to be "an intuitive VCS unlike git". The idea of composing patches is interesting, but I haven't got around to actually trying it yet.

[0]: https://pijul.org

[indymike]

Google docs?