This article eloquently summarizes how I try to use git: To efficiently write a story of the code's development history that maximizes the productivity of your future self and/or other developers who may read it later. If the story does not consist entirely of literal historical truth, so be it. A developer's concern should not be the exact preservation of the way things were created, but the telling of a story in a way that is most easily understood.

If there are complicated merges, dead-end changes or separate lines of development that inadvertently became interleaved, the branch is crying out for a rebase. (As a practical matter, you should do rebases on a local throwaway temp branch, then either delete and recreate the original branch, or checkout orig-branch and git reset --hard temp-branch.)

I like how Joe points out that rebasing raises the same issues as time travel, namely paradoxes. If you have rebased commits that others have pulled, then you've created a situation where a commit both does and does not exist.

Also interesting is how rebasing can reorder the dates as seen in the log. All that git really cares about is the parentage of some commit.

Good and insightful post.