

Version Control for Poetic Time Travelers - listrophy
http://blog.begriffs.com/2012/08/version-control-for-poetic-time.html

======
csense
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.)

------
twopoint718
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.

