Richard Hipp - Git: Just Say No

This reminds be of a talk I watched by Richard Hipp, "Git: Just Say No" [0] where he discusses a "top 10 git enhancements" list, as of the time (4 years ago.) It's a good talk, and caused me to discover Fossil SCM. Sadly I've yet to try/use Fossil, and my teams still use git. [0] [VIDEO]

> Take a look at this image and tell me it’s immediately intuitive I'm using Git, there's nothing intuitive to be found here. On a possibly related note, I watched a talk by D. Richard Hipp (I don't remember which one - edit: probably "Richard Hipp - Git: Just Say No"[1]) where he compared it with Git (a lot) and explained how Fossil keeps everything, there's no throwing away of history, no need for rebasing (at least as a workflow). It sounded nice - refreshing, even. I'm going to start using it for some projects and see how I get on, because frankly, I'm tired of Git and this need to strategise saving copies of my work , because that's basically what it does. Sometimes I even pine for the days I used to version zip files… [1] [VIDEO]

Here is a (somewhat old) talk by Richard Hipp, the author of SQLite about Git: "Richard Hipp - Git: Just Say No" [VIDEO] I use Git every day, but I am curious about Fossil and have been researching it for a while. I am not planning on changing, as I need to get to the bottom of some data corruption events I have seen in their forums. Not saying it was the fault of Fossil, just that it requires more research on my side. We should not forget Version Management did not start with Git but has a vibrant history that began with SCCS, RCS, CVS, ClearCase, Perforce, SVN, etc... As I used all the systems above except for SCCS and RCS I would advise for some caution here on thinking Git core flows are the one true way. I know the authors of ClearCase though the same way :-) If the author of SQLite advances some arguments around the proper way of doing version management, I would advise to error on the side of caution and listen at least a second time. Do not throw away your own experience and insight, but at least listen carefully. Don't just dismiss the arguments as quickly as some are doing here. I found this recent thread very useful not only as a features comparison but also as a core reminder of what the main use case for Fossil is: "Lessons from 13+ Years of Fossil" : [LINK] "Fossil's reason for existence, plain and simple, is managing the source code for sqlite3. That's the scope of project it was initially envisioned for, and that size of project seems to be quite average for t