>In my opinion in a collaborative environment it is immensely
>useful to know about how a feature / bug fix was developed.
>
>Hiding away the development of a feature into one large
>commit makes it harder for people to review.
this is exactly what be pro-rebasers were talking about.
Nobody of us wants to do one big huge commit that contains the whole feature.
Everybody of us wants small, self-contained commits, every commit fixing or adding one specific thing.
What we don't want is a commit adding a thing, quickly followed by another commit "forgot to add this file", because that later commit provides no value to a reviewer.
What we rebasers are talking about is forging the history in a way that a patch reviewer can go over every single commit and, in one glance, decide whether that patch makes sense or not.
Let's assume it's the old days of svn: A whole file is the smallest unit of change you can commit and there's no way to change history.
Let's further assume that you want to add a new feature to a file. While doing so, you also notice that there's a bug in another part of that code in the same file that became apparent while writing your feature.
Your feature only works with the bug fixed, but the bug fix also makes sense independently of the feature.
In the old days, when committing that file, you have two options for commit messages:
1) "adding feature foobar"
leaving out the fact that you also fixed a bug. This is bad if your bugfix contains another bug and I have to dig in the history, wondering why you changed this seemingly unrelated piece of code. If I have to review the code, I will have to ask you, why you also changed a seeminly unrelated piece of code.
2) "adding feature foobar and fixing bug bar"
this is better, but weren't you thought that a commit should only do one thing? This clearly does two.
At that point, you could use diff, patch and an editor to remove the feature but leave the bugfix in. Then you commit that as "fixing bug bar", followed by more diff and patch to get the feature in, which you commit as "adding feature foobar".
Fine, but very cumbersome, so hardly ever done.
Git, on the other hand, with the help of "add -p" and "rebase -i" makes exactly this possible and turns something incredibly painful into something you can do with closed eyes in your sleep.
And this is why there is this vocal pro-rebasing-crowd.
We EXACTLY NOT talking about mushing everything together in a big commit
We are talking about creating MANY, MANY more SMALLER commits that are independent of each other and thus much more maintainable.
Case in point: Since we migrated to git for our product and since everybody learned about rebase and began using it, we made the same amount of commits in one year that we did in tree previous years.
I would be seriously upset if somebody used the power of rebase to create big huge commits and wanted to push them to our main repo. This is not what we are advocating rebase use for. Not at all.