Github user miguelaferreira commented on the pull request:
https://github.com/apache/cloudstack/pull/527#issuecomment-117186219
As long as people make good commits, that are atomic, capture relevant
changes together, and have descriptive messages, IMHO squashing only make
things worse.
If you squash commits, all you get is less commits. Some people might say a
cleaner master branch.
I won't discuss aesthetics here. I will try to be objective.
With less commits you also get larger commits. That means that in a change
set (e.g. a PR) where a large number of changes are made, these changes are all
bundled together. That forces the reviewer to take all the context at once.
With more commits you get smaller commits. That allows the reviewer to take
chunks of context at a time. And, in addition, if the reviewer wants/needs to
get all the context at once, it is easy to make a diff between the first and
the last commit in the change set (Github offers both per commit view and total
diff view, just see the tabs on top of this PR).
If you will, this is comparable to reviewing a class will several small
methods or reviewing a class with one big method.
Another interesting aspect that should be considered is reverting commits.
As you may all know this can happen quite frequently. With smaller, atomic
commits, it is easer to revert a change (e.g a bug introducing change) in a
particular part of the code (while leaving the rest of the code untouched). It
is easier because (1) the small commit isolates the change; (2) in the presence
of conflicts these can be fixed iteratively, in small steps.
Finally, I would like to point out that smaller commits allow the developer
to convey more information about each change. If you squash a set of commits
you loose the description of all the small changes.
Do we really want to go towards less information about code changes? Or do
we want to have the developers write a bullet list of the changes they made and
assign them to parts of the code? There simply isn't any other way to preserve
this information.
Of course that, as I already said, all this only makes sense if:
* commits are small;
* atomic;
* have good descriptions.
And that is, simply put, entry-level development discipline.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
