[js2]

For the same reason you refactor code, it is often useful to refactor your commit history _before_ you publish it.

And just because you use rebase, doesn't mean you don't also merge. I often use git like this:

  git checkout -b feature origin/master
  while not done with feature:
    edit, save, commit -am "added blah"

My commits are so small that I can write the entire commit message on the command-line. When feature is done from a coding perspective, I then:

  git rebase -i origin/master

Now I can squash together commits, possibly dropping some, re-ordering, etc. Generally, presenting my change in such a way that I have small'ish, self-contained changes that are easy to review, and with no obvious mistakes.

Now that feature can be published for review. I happen to have setup gerrit for this purpose, but for git.git, you'd use format-patch and you'd email the patches, and that works well too. Each patch needs to be small enough that your reviewers aren't overwhelmed by it. (Smaller commits also help later on if someone has to git blame your code, or if they have to deal with conflicts when merging with your code.)

Rebase is also how you'd incorporate feedback to your patch series. Typically I'll put the correction on-top of my patch series, then squash it into place with rebase -i.

Finally, once your feature is done/done:

  git fetch
  git checkout master
  git reset --hard origin/master # I use master only for integration
  git merge --no-ff feature
  git push origin master

Rarely, I will rebase topic onto a latter version of master, but only if I need some functionality that was added to master since I began the feature. I could merge master into feature, but that then makes feature harder to review.

$0.02.

[EGreg]

IMHO, a version control system shouldn't provide facilities for people to edit the history, but instead, to edit meta-information about the history. What git needs is probably a meta-history that gets aggregated during pushes. But if you wanted to see all of your own warts, you should be able to, for the philosophical reason that a VCS isn't supposed to let you "cheat".

"But," you say, "I want to prepare my patch to look super-nice when I publish it to the world!" Fair enough. Then edit your meta-history since that is what the VCS will send. Right now, you can already do this in GIT by creating a specific branch and pushing only IT. Can't you? So why rebase

[__david__]

I think what people with your opinion are missing is that in a VCS without rebase/amend capabilities all that happens is people like me commit way less often. That is, I get everything working and fully tested and only then start checking in my code. With git I can commit almost immediately, before everything is tested and working. It allows me to start organizing the patches early and keep them up to date as I finish doing the task at hand. In that sense it is not rewriting history. I'm creating history. I don't push my code to the central repo until it's done and after that it doesn't get rebased.

Should I start committing every single version of the code I've ever saved so I can see all my false starts and typos? Maybe but there's not a lot of good information to be had there.

[zrail]

There's More Than One Way To Do It. Some people find rebase more convenient, some people cherry-pick commits onto another branch, or squash merge them into another branch and merge that into master. Or whatever. Git is fast and powerful in part because it's really stupid. Building another layer of "meta-history" into git would complicate things immensely.