Cc: Ray Lee <ray-lk@...>, Linus Torvalds <torvalds@...>, Jesse Barnes <jbarnes@...>, Rafael J. Wysocki <rjw@...>, <torvalds@...>, <linux-kernel@...>, <linux-acpi@...>
Andi,
say you create patch P1 against tree version T1 creating tree T2
you then rebase patch P1 against tree version T5 creating tree T6
people tested tree T2, they didn't test tree T6. while the changes made by
patch P1 are still the same, there may be other changes that interact with
things (and not nessasarily by chnaging the same area of the code, they
may change memory layouts, timing, etc)
when someone is trying to track things down they can no longer recreate
the state of tree T2, you've wiped the record of that from history. all
they can do is to test version T5 and T6.
the other approach is that you create patch P1 against tree version T1
creating tree T2, this then gets merged with tree version T5 upstream
creating tree T6.
now when someone goes to track down a problem they can see all four tree
versions, T1, T2, T5, and T6. they can not only test that T5 works but T6
doesn't, but they can test that T2 works as well. They then can immediatly
start looking for other interactions that are the result of the merge (and
what's different between T1 and T5) rather then focusing just on 'what did
patch P1 change'
now, it's also not good to have large areas of non-bisectable trees and
bugs with their fixes a lot later, but with distributed testing and
development you will never completely eliminate this.
there are things that you can do to minimize that, and using some number
of topic branches seems to be one of the big ones (and I'll point you at
the other explinations from this thread that have focused on what those
are)
David Lang
--
