

Rebase Considered Harmful - telemachos
http://changelog.complete.org/archives/586-rebase-considered-harmful

======
telemachos
To anticipate some misunderstandings, I posted this in the light of Jeff
Kreeftmeijer's latest post, "The magical (and not harmful) rebase"[1][2]. I
had never read the full original "Rebase Considered Harmful" article, and
after reading both posts, I'm not sure how I feel about rebase overall. Since
I use Git, I'm curious to hear more from others.

Some people worry about rebase (reasonably) in terms of messing up other
people's repos, but that seems like a simpler problem. Just don't do it.
(Everyone would agree you shouldn't mess with history that is already public.)

I'm more curious about rebasing to produce a "clean" history. I'm not sure I
like the idea of all history looking like a smooth, linear progression. (Let's
set aside simple amends for typos and or leaving one file out of a commit.
Those seem trivial and again not controversial.) If the point of rebase is to
always smooth things out, I worry about the larger picture being lost. Anyhow,
I wonder what more experienced people have to say. (Edited to make my concerns
clearer.)

[1] [http://jeffkreeftmeijer.com/2010/the-magical-and-not-
harmful...](http://jeffkreeftmeijer.com/2010/the-magical-and-not-harmful-
rebase/)

[2] Discussion of [1] here on HN:
<http://news.ycombinator.com/item?id=1779481>

~~~
madhouse
I use rebase often: I develop on a feature branch, experiment there a lot, and
before I push it, I rebase it to squash the thing into more managable and
straightforward pieces. (I push my branches public when they're ready, and
when I won't rebase them anymore)

For example, there's this project where the test environment is on another
system, and I hardly ever test locally. So when I break something, there's a
good chance I won't notice that until the test runs. At that point, I make a
small commit to fix it.

I could push that all out, and merge the whole thing onto my master branch,
but that would be a lot of useless clutter: development mixed with random
fixes. I prefer my development line reasonably clean, so I rebase & squash
things together before making them public.

This doesn't mean that my whole feature development will be one big patch, no.
But it will be a series of clean changes, as it should be. Easier for everyone
to understand later.

One line of development will look like a smooth, linear progression, but there
can be many similar feature branches, which get merged to master at various
points, and that line will not look all that linear. Smooth - hopefully, but
not linear.

