Git development
 help / color / mirror / Atom feed
* If anyone feels like hacking git-rev-list --bisect...
@ 2007-06-27 18:53 linux
  0 siblings, 0 replies; only message in thread
From: linux @ 2007-06-27 18:53 UTC (permalink / raw)
  To: git

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.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2007-06-27 18:53 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-27 18:53 If anyone feels like hacking git-rev-list --bisect linux

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox