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