[ghusbands]

You present a clean history, yes, but not a correct one. The context in which you made your changes, often noted as important, has been lost.

[deathanatos]

In the general case, I agree; rebases do lose a bit of context. As a code reviewer, however, I find the reason I most often ask for a rebase & squash is that the "context" that I'm asking to lose is simply the author isn't taking the proper time to think about what he or she is doing, and it shows, in commit messages like,

  * I can't spell
  * fix tests, too, lol
  * fixed for real
  * fixed
  * minor touchup
  * Implement feature foobar from issue #123

Once the code review has completed, this history is not going to ever be useful again; worse, it impedes someone looking through the logs for useful history, and other operations like cherry-picking this feature to a branch.

[klodolph]

I'd argue that what you're describing shouldn't even be called a rebase, even though you could use "rebase -i" to accomplish it. For example, I just use "reset --soft ; commit" instead.

[jsolson]

Presumably each change in the history will be reviewed, though, right? One assumes the point of doing rebase -i to reorganize commits during review is to present a history with MORE and BETTER context -- one which can be more easily reviewed and understood and where changes can be accepted in-order and piecemeal.

[kyle4211]

I often just use `rebase -i` as a way to squash + fixup commit messages.