On Mon, 7 Nov 2005, walt wrote:it will work, but it's not optimal. this is exactly what git bisect is designed for. you tell it that the prior night's version was good and the current version is bad. It picks a version 'halfway' in between the two and you test that. tell git if the test failed or not and it will then give you the next one to try. repeat until you identify exactly which commit triggers the problem. unfortunantly I can't trivially point you at the right place in the docs. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - 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
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| David Woodhouse | [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more dr... |
| Philipp Marek | Re: sys_chroot+sys_fchdir Fix |
| Greg Kroah-Hartman | [PATCH 008/196] Chinese: add translation of volatile-considered-harmful.txt |
git: | |
| Krishna Kumar | [PATCH 9/10 REV5] [IPoIB] Implement batching |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
