This describes a real problem I've had twice in the last two years while tracking Linus's kernel tree: I update my local kernel sources every morning using cg-update (formerly bk-pull) and compile and install and reboot the new kernel. Okay. On rare occasions I get a kernel panic on reboot. So... I know that something Linus committed in the last 24 hours is responsible for the problem. The last two times this happened I was able to guess which commit caused the problem and I emailed the developer off- list and got the problem fixed very quickly. (This is why I love open-source software!) My worry: what happens when I'm not smart enough to guess which developer to email? My first instinct is to back out the most recent commits one-by-one until the bug goes away. First: is this an optimal tactic? Second: how to back out individual commits using git or cogito? I suppose this is already spelled out in the docs, but I invite everyone to point me to the relevant places in the docs that have escaped my attention so far. Thanks! - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Pierre Ossman | Re: [RFC][PATCH] cpuidle: avoid singing capacitors |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Greg KH | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| Rene Herman | 2.6.26, PAT and AMD family 6 |
git: | |
| Jesper Krogh | Re: NIU - Sun Neptune 10g - Transmit timed out reset (2.6.24) |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Arjan van de Ven | Re: [GIT]: Networking |
| Radu Rendec | htb parallelism on multi-core platforms |
