For the same reasons Dennis mentions, I tend to prefer 2. Actually 2b
Before pushing a PR, I rework my history and squash some stuff together
(and occasionally split one commit in two) so that the commit history
reads like a novel onto the features:
- FOO-123 add indexing for time warp
- FOO-123 add query support for time warp
- FOO-123 add time warp tests
This is not exactly the flow in which I have worked but it is made to eb
easier for later persons to read and enter into the feature.
I all put all unrelated commits like typos, style and unrelated bug
fixes before so that they could be applied even in the main feature is
rejected.
Emmanuel
On Sun 2013-09-08 22:59, Dennis Reed 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(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> --
> Manik Surtani
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev