Hi Claudio,

>>
>> I applied this series.  I did re-order and split the patches to be in
>> accordance to our patch submission guidelines.  Please refer to the HACKING
>> document for more details.
>>
>
> I thought that taking care not to break compilation was more
> important. Sometimes I avoid to split patches to avoid breaking the
> compilation. Especially when it is necessary to change header files.
>

Understandable, however we actually optimize the other way.  Because all 
patches are thoroughly reviewed we tend not to need git bisect often. 
In situations like these the primary goal is to still follow the general 
patch submission guidelines.  e.g. breaking up patches per directory. 
The secondary goal is to keep git bisect happy if at all possible.  If 
it is not, then you are allowed to break it.

The rules of thumb are
1. Break up patches appropriately (e.g. in line with HACKING)
2. When adding new code everything must compile individually
3. When refactoring code (which should not happen often), try very hard 
to do same as 2.

Regards,
-Denis