You mean Darcs [0], which kind-of-sort-of does the rebase automagically. Whenever it can, at least.
Fortunately, Git does 99% of that, and with rebase it's just the right for the job. Especially with git-rerere enabled.
As far as I am concerned, the need to (sometimes!) do rebase by hand is artifact of Git's commit history being strictly ordered by time. But just try to remove that constraint, and whomever considered rebase complex, will go completely crazy ^^
Came here to say this, and drop this video[1] as well. It explains the differences between git and darcs/camp using an example editing session with both tools.
But what about changes that depend on each other that don't happen to edit the same line? Neither git nor camp will be able to detect that (since it relies on semantic knowledge of your application). Merge conflicts are places where the VCS can't even be wrong about what to do, not places where it won't be right.
Git's commit history being strictly ordered by time
That's the default of git log output but can be adjusted via --topo-order and --date-order. It's also worth pointing out that git commits have two timestamps, the author timestamp which is not normally affected by rebasing/amending, and the commit timestamp which is reset by rebasing/amending. Git log (again by default) shows the author timestamp but orders by commit timestamp.
Fortunately, Git does 99% of that, and with rebase it's just the right for the job. Especially with git-rerere enabled.
As far as I am concerned, the need to (sometimes!) do rebase by hand is artifact of Git's commit history being strictly ordered by time. But just try to remove that constraint, and whomever considered rebase complex, will go completely crazy ^^
[0] http://darcs.net/