[Development] Cherry picking to replace a change set

[Knoll Lars]

On 9/3/13 6:30 PM, "Thiago Macieira" <thiago.macieira at intel.com> wrote:

>On terça-feira, 3 de setembro de 2013 11:42:04, Oswald Buddenhagen wrote:
>> you did, however, make no effort to substantiate your position.
>> an argument against your interpretation is for example bisectability.
>> also, it's just plain illogical to tear apart an allegedly "too complex"
>> change, because then assessing the pieces requires adding "external"
>> context. which is just a less handy way to review one big change.
>
>I've made it clear that I prefer reviewability (now and in the future)
>over 
>compilability, in extreme cases.

Compilability should be there. But passing all test cases for a series of
patches that refactor a larger chunk of code (as I'm currently doing in Qt
Qml) is IMO not possible without sacrificing the reviewability of patches,
as they simply get too large in many cases.

>It's an opinion. As such, it does not have to be substantiated.

It's a matter of taste and what one considers more important.

IMO the general policy of having atomic commits that compile and pass all
tests is a good one.

There are however (as with any good rule/policy) exceptions. These usually
come in when a patch series does larger changes to the internals of a
class or module. Requiring that all test cases pass on all intermediate
commits is in these cases often not feasible and would require squashing
the whole patch series into one commit, that is later on neither
reviewable nor understandable.

Cheers,
Lars