I commit a lot. A lot a lot. Sometimes those commits don't actually work for some reason. For example, when I leave for the day and I'm in the middle of a task, I like to leave a failing test so I have something to pick up on immediately when I get in for work in the morning. I fairly often commit this state.
When it comes time for me to publish my changes, I very much do not want those unpublishable intermediary states going out into the world. Rebase lets me break apart and combine them into rational, test-passing changes that have cogent, readable commit messages instead of "blah", "blah again", "what the hell i forgot to frob the flubulizer!?", etc.
In sum, yes it's a heavy-handed tool. Yes you're "destroying" history, but often that history is extremely ephemeral and mundane and not germane to the actual meaning or effect of the change.
This is the difference between distributed VCSes and centralized ones like svn.
When I create a change/feature it usually ends up being separated into multiple commits--usually some generic feature change somewhere followed by the specific changes for whatever I'm doing. In the centralized world I'd just work in my directory for a week and then go through and parse out the changes and check them in (generic first, then specific).
With git I can check them in early but not push them. They exist as living breathing patches while I work on it. I'll amend and rebase them like crazy. After everything is tested and working I push the set up to the main repo so others can get at them.
The important thing is that you don't amend/rebase the main repo. That is messing with history and is annoying to anyone who already grabbed the original changes. But messing with your local repo isn't rewriting history--it's not history yet. It's a set of changes that are still in progress.
It's not like there are clean independent commits just floating around in there with the junk. It's the amalgamation of the junk that produces the clean commits, thus the need for rebase. As someone else in this thread talked about, being able to tweak my commit history has changed the way I've approached coding. I commit often because I know I'll be able to go back and rewrite history before other people have a chance to look at it.
I'm just asking, why can't you make a new branch and merge-commit every 3rd commit to it, with a better message? It would preserve the philosophical "involatility" of history.
Ok, so the philosophical "involatility" is preserved, sure, but that's rather a large amount of work to do to preserve unworkable deadends and silly commit messages and broken builds and the like.
Also, it introduces a huge non-linear mess into the commit history that can be hard to untangle. Just looking at topic branches in a normal tree with gitk can be hard. Can you imagine looking at topic branches and these junk branches at the same time?
You can just create a new branch before you start the rebase, which achieves exactly the effect you ask for. Rebase is how you "create a new branch with only the clean commits".
But, most of us don't bother copying before rebasing. The reflog makes that pointless from a safety perspective and, without the safety need, there's not much reason to copy before rebasing.
Also, I almost always work on topic branches and do my rebasing there. This may be a crucial point that others have missed. Personally I don't rebase on master.
Why not? The end result is exactly the same. You have a little branch of your work and then when you pull next time it gets merged back in. You can even create a named branch for it after the fact by sticking the hash into .git/refs/heads.
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.
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
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.
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.
This is why people don't like rebase, but if you just tell people "never start a rebase farther back than master" the problem magically goes away. Tada!
I'd add that it's only a problem as team size grows. If the only other people who might be affected are sitting nearby, I can say "has anyone pushed since <commit>" and happily push -f my rebase in most cases.
To track a remote SVN repository. To edit commits earlier in history when you need to correct minor bugs/CR comments/commit descriptions. Edited to add: squashing lots of tiny safety commits into a commit with an entire feature in it.
The svn issue seems under-appreciated. In my experience, far and away, the best way to merge subversion branches is to pull them in with git-svn, rebase, and push back to subversion. I've done this more than once for projects that I'm only tangentially involved with.
