[dexen]

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 ^^

[0] http://darcs.net/

[seliopou]

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.

[1]: http://projects.haskell.org/camp/unique

[aidenn0]

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.

[Argorak]

Yep. Sadly, camp seems pretty much dead.

[Argorak]

I found darcs quite intuitive to use and not crazy at all. Yes, its not ordered by time, and so is your rewritten history.

[js2]

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.