If anyone feels like hacking git-rev-list --bisect...

[linux@horizon.com]

I'm trying to bisect kernel bug A, but I keep running into kernel bug
B which causes a crash on boot.  (But was fixed, so I don't need to think
about it much.)

that is, my revision history is something like:

G...........G......XXXXXXXXXX.....B...............B
G = good
B = bad
X = I can't tell


While I can do things like "git-reset --hard HEAD~250" to try to get past
the problem, it's an annoying bit of guessing to find good values, and
if my problem is one some branch, I'd rather explore a different branch.

How much nicer, I couldn't help thinking, if bisection could be told
to look for a ratio other than 1/2.  Then I could ask for the 1/3 or 2/3
point instead.

That would also be helpful in cases where the "good" or "bad" cases
differ significantly in testing pain.  For example, if "bad" forces
an fsck, or if "good" takes a couple of hours of stress-testing
to be really sure.

I *think* it's just a tweak to builtin-rev-list.c:halfway(), but the
code that calls that is rather intricate.

So if anyone feels like attempting it...

Adding the relevant UI to git-bisect would be relatively straightforward.
A new command to re-bisect from the initial state would allow evading
unbuildable commits, and maybe a way to set a preferred split ratio.