IMHO, both Git and Fossil are wrong here. Fossil requires users to either commit stuff they don't want to see later, or hack away until finished, cherry-pickin

IMHO, both Git and Fossil are wrong here. Fossil requires users to either commit stuff they don't want to see later, or hack away until finished, cherry-picking changes as necessary. This isn't a good workflow for everybody. Git allows users to do anything they want, but your Linux master branch may not be the same as Linux Torvalds' master branch, and history can be changed at anytime, while merge commits can be completely rewritten, losing the actual merge information. Both of these are wrong. There should be a way to make WIP changes without committing it nor committing to it. (Yes, those are different things.) But there comes a point at which a change should be committed and committed to, to never change again. (With the exception of the nuclear option of erasing accidentally committed secrets and the like.) Fossil is too rigid. Git is too flexible. There is a middle ground. My design for such a VCS would have two kinds of commits: saves and full commits. Saves would be WIP stuff; anything goes. They would also be on auto-generated branches. Once WIP stuff is done, it should be to be rebased, squashed, merged, and/or cherry-picked into actual full commits on the branch that the saves created a branch off of. But once those commits have been created, they are there forever. They should be a commitment. (I love the double meaning of the word "commit" here.) With this design, people could have their cake and eat it too: they could have WIP stuff that they can still massage into a history they like, but then they would also have solid, reliable history with proper merge commits.