Darcs was probably the most interesting VCS in this space. It made a lot more sense because it was more about managing patches (or features) instead of history that we do now with git.
IIRC Darcs had a lot of momentum with it until there was a problem discovered with it's algebra that allowed itself to go into an infinite loop. And then it died.
At least with git, I can think in terms of DAGs which should be in the knowledge of any serious senior software engineer.
I don't know if managing patches makes more sense than managing revisions. The truth is that you need both.
Sometimes you are authoring patches, and reviewing patches. But sometimes you are releasing/trying/building revisions, and you are releasing revisions.
Moving to the dual representation fixes some issues and brings its own. I think the only reason why some people think it is better is because they haven't used it long enough to get frustrated by the new issues, the way they had time to be frustrated by the old dual issues.
Managing patches or features seems to be easier to think about: "I want feature X in this build but not Y for reasons even though Y was in the last build..."
But language (software or otherwise) doesn't really work that way.
You could imagine a novel written using a VCS where in one branch of the novel a main character lives throughout the novel dying at the end. In another branch, that character dies in chapter 1. Now try to merge the two branches automatically.
Sure, you might get a novel, but the character lives on after chapter 2 nonsensically.
That's the same issue with programming languages. "Syntax" is not the same as "Functionally Coherent".
IMO managing revisions makes more sense than managing patches. Yes yes, I know about commutative patches and all that, and no I don't need that. I do reorder patches sometimes, and when they yield the same tree that's interesting, but not that interesting.
You need both. Even with Git (a snapshot-based system), some commands take a hash as a revision and some take a hash as a change (e.g. checkout/rebase/reset/bisect vs cherry-pick/revert/amend). You'll hear both in common parlance too ("this commit doesn't pass tests"/"this commit is deployed"/"rebase onto this commit" vs "I did the last commit"/"this commit is too big"/"that commit broke X").
You really have to think of commits as both, neither view is entirely sufficient.
> A commit hash identifies both a patch or a revision, that's my point.
Strictly speaking, no. A commit hash identifies a tree. There is no patch stored, nor is a patch bound into the commit hash in any way. The patch is indirectly implied as the differences between the new commit's tree hash and the preceding commit's tree hash.
For people looking at Darcs, Pijul[0] is an interesting advancement in the space, as it solves the exponential merge time problem that can make Darcs intractable.
Sadly Pijul also doesn't have the consistent maintenance one would like to see from a daily-driver VCS.
IIRC Darcs had a lot of momentum with it until there was a problem discovered with it's algebra that allowed itself to go into an infinite loop. And then it died.
At least with git, I can think in terms of DAGs which should be in the knowledge of any serious senior software engineer.