Request for review: my patch queue for 2.6

[Sam Lade]

On 27/12/11 08:56, Bart Cerneels wrote:
> On Sat, Dec 24, 2011 at 15:40, Matěj Laitl <matej at laitl.cz> wrote:
>> On 20. 12. 2011 Bart Cerneels wrote:
>>> Just make sure you squash the commits that belong together :)
>>
>> Do you mean some specific commits? E.g. there are 3 UpdateCapability removal-
>> related commits, but each one stands on its own (with commit message
>> describing the specific change) and everything is perfectly bisectable. (I must
>> say I'm not a big fan of squashing related changes - I instead prefer the
>> Linux-kernel way of thinking with git: make very granular commits so that it
>> is `git bisect` who finds erroneous changes, not you)
> 
> One revertible commit, not a whole series that would make using git
> bisect take way to long to be useful.
> 
I disagree; there is no bisect-related reason to encourage squashing
commits. The effect of a large block of commits on total bisection time
is negligible since bisection time is O(log_2 (n_commits)), unless the
problematic commit lies within the block in question, but then
equivalent precision to a squashed commit can be attained in a similar
timespan by simply stopping the bisect once the range has been narrowed
to within the block - but you also have the option to continue the
bisect and narrow down the problem further.

Sam