> The Git version control system has been causing us misery for 15+ years. Not having git and using most other VCS (fossil and mercury are pretty good, too) cr

> The Git version control system has been causing us misery for 15+ years. Not having git and using most other VCS (fossil and mercury are pretty good, too) creates way more misery. > No one bothers to consider: what are the workflows that people actually want to do? Well, here is where the problem is. Git has some fantastic workflow features that most people don't learn or use (https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks). Workflow is also problematic because it is exactly where people will demand a wheel, except for more round, every time. So... how could it be better? Abstract it away to the os and filesystem so it is just part of the routine. Having full support for versioning everywhere would help because many of the rough edges with git are caused by having to support multiple OSes. A lot of confusion is that you have to use git's own tools or do an add/commit cycle for what should just be os file commands. These issues exist because git is not an OS level tool. Imagine commands like find or grep can return the file and version... imagine being able to just mv \dir;crusty-branch \new-dir and it just works. Back in the day, VMS did primitive versioning and it was quite nice (ie \dir\myfile.txt;22 where 22 was the version). Adding versioning like this also would encourage vendors to have sane file formats, so they could be versioned by the OS and pick up almost free change history features. Slapping a UI on git isn't all that helpful - many, many users just use git from the ide or command line, anyway. As far as workflow goes, the author has a point that git does not come with a lot of strong opinions or obvious ways to do things out of the box.