Git rebase loses history, then why rebase?

Question

I\'ve been looking into rebasing with Git over the past couple days. Most of the arguments for rebasing say that it cleans up the history and makes it more linear. If you do

Answer 1

You do a rebase mainly to rework your local commits (the one you haven't pushed yet) on top of a remote branch (you just fetch), in order to solve any conflict locally (i.e. before you push them back to the upstream repo).
See "git workflow and rebase vs merge questions" and, quite detailed: "git rebase vs git merge" .

But rebase isn't limited to that scenario, and combined with "--interactive", it allows for some local re-ordering and cleaning of your history. See also "Trimming GIT Checkins/Squashing GIT History".

why wouldn't you want the repo history to reflect all the ways the code developed, including where and how it diverged

• In a centralized VCS, it is important to never lose the history, and it should indeed reflect "all the ways the code developed".
• In a distributed VCS, where you can do all kind of local experiments before publishing some of your branches to upstream, it makes less sense to keep everything within the history: not everyone needs to clone and see all of your branches, tests, alternatives, and so on.