From what I can see: easier control over tracked/untracked status of files; no stage (might be considered a disadvantage, though I'll wager a good interactive commit feature would render a stage unnecessary), automatically commit everything by default, much simpler concept of what a branch is and isn't; no fetch at all, just merge.
I like this experiment quite a lot. It's clearly very incomplete and lacking of features, but I feel that it gets the basic concepts more right than Git does. For example, the idea that merging from a local branch or merging from a remote branch is the same, is very nice and simple. Sure, it's not like 'git pull' vs 'git merge' is a lot more work, but still, I'd like to not be bothered by the difference.
There's a whole bunch of edge cases still missing here, I fear, but I really like where this is heading. Would use.
The staging area is sort of a UI for "interactive" commit. But one that can persist the partial commit state across multiple commands, or until you can finish the work tomorrow.
An interactive commit interface which loses the accepted/rejected changes if you have to close it for one reason or another is going to be worse than the git UI for interactive commits.
I like this experiment quite a lot. It's clearly very incomplete and lacking of features, but I feel that it gets the basic concepts more right than Git does. For example, the idea that merging from a local branch or merging from a remote branch is the same, is very nice and simple. Sure, it's not like 'git pull' vs 'git merge' is a lot more work, but still, I'd like to not be bothered by the difference.
There's a whole bunch of edge cases still missing here, I fear, but I really like where this is heading. Would use.