I jump in this discussion hoping to have some more insight on git and to report my experience as a tester. I consider myself as half-literate in this (I am here since 1991, more or less, and I am able to compile a kernel and even hand-apply a patch, although I am in no way a kernel programmer). On Tue, 2007-11-13 at 18:01 +0100, Adrian Bunk wrote: > The small instruction below is enough for everyone who is able to > build his own kernel to do a git bisect. > # start bisecting: > cd linux-2.6 > git bisect start > git bisect bad v2.6.21 > git bisect good v2.6.20 > cp /path/to/.config . > This was what I did in my (in the end almost successful) bisecting when trying to find the mmc problem (see the thread named "2.6.24-rc1 eat my SD card"). This is true in theory, but it has some problem. The "this commit does not compile is the easiest and in man git-bisect it's explained how to solve it. The changes in .config options, added or removed, are another problem when jumping back and forth from version (I was bitten by the gadzillions new options added to hda-intel alsa driver, but well, that is solvable with a bit of attention). The main problem I had, and that stopped me to arrive to a definite is this situation: j version-bad i h g unrelated (but similar) bug corrected f e d unrelated (but similar) bug introduced c b a version-good (d was the series to change drivers to use sg helpers, and g was a "fix fallout from sg helpers" patch). Now I have a series of kernels (d, e, f) that did not work at all and so I cannot mark them good or bad. With the number of patches added in the free-for-all week, this is a very probable scenario. There is a way out from this using bisect? Romano PS as a suggestion, I think that added a "Reported-by", or "Tested-by", or "Debugged-by" attribution in the repository, as happened to be in the MMC case, is a nice an d welcomed reward for the effort. -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
