cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From miguelaferreira <>
Subject [GitHub] cloudstack pull request: As an operator I want to be able to chang...
Date Tue, 30 Jun 2015 13:32:14 GMT
Github user miguelaferreira commented on the pull request:
    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
    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 or file a JIRA ticket
with INFRA.

View raw message