[infinispan-dev] To squash or not to squash

Mircea Markus mmarkus at redhat.com
Mon Sep 9 13:07:02 EDT 2013


All very good points, thanks for the feedback!

On Sep 9, 2013, at 4:59 AM, Dennis Reed <dereed at redhat.com> wrote:

> I think this has the biggest effect on those of us porting fixes to 
> other versions.
> 
> When porting changes, I've seen issues with both single commits and 
> multiple commits:
> 
> 1) When doing one commit, it's too tempting to bring in unrelated 
> changes, such as unrelated formatting changes.
>   This has actually been a big pain for me a number of times in JBoss 
> Cache/Infinispan.
> 
>   Being strict about 1 commit = one logical change, and nothing 
> unrelated would help a lot with this.
> 
>   One large commit is also harder to cherry-pick when a change affects 
> code that did not change much between versions, as well as code that did.
> 
> 2) If the commit messages don't make it clear that multiple commits are 
> related to fixing the same issue, some important changes may be missed.
> 
>   Making sure it's clear from the commit messages that they're all 
> related to ISPN-XXX mitigates this.
> 
> My vote is (2), as long as the commit messages make it clear the changes 
> are related.
> 
> -Dennis
> 
> On 09/06/2013 07:50 AM, Manik Surtani wrote:
>> My vote is (1).  Multiple commits, as you say, may leave the code base unstable and thus not atomic.  Further, multiple commits may cancel each other out in places (reverting or fixing code from a previous commit, etc) so squashing will actually make reviewing easier and cleaner.
>> 
>> On 6 Sep 2013, at 13:05, Mircea Markus <mmarkus at redhat.com> wrote:
>> 
>>> When issuing pull requests people split the added functionality corresponding to a single JIRA issue into multiple logically related commits. (If they don't they should as this makes reviewer's life much easier).
>>> Do you think these commits should be squashed into a single commit before integrating (1) or should be integrated as such (2)?
>>> Note that for (2), especially for very large features, internediate commits might not compile/pass the suite.
>>> 
>>> My preference is for (2) as this way the history reflects the flow of developement and makes history easier to read.
>>> 
>>> Cheers,
>>> Mircea
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> --
>> Manik Surtani
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list