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.