Re: git-bisect is magical

[Linus Torvalds <torvalds@osdl.org>]

On Mon, 9 Jan 2006, walt wrote:
>
> Arthur C. Clarke's Third Law states:  Any sufficiently advanced
> technology is indistinguishable from magic.
> 
> You guys have done it -- I can't distinguish git-bisect from
> magic.  It's wonderful, and thank you!

Hey, I'm pretty damn happy with it myself, if I may say so ;)

It's the _one_ feature that we really never had with BK, and that git does 
really really well.

> I have one minor suggestion for howto/isolate-bugs-with-bisect.
> Linus states:
>        git bisect good ORIG_HEAD       <- mark ORIG_HEAD as good (or
>                                            whatever other known-good
>                                            thing you booted last)
> 
> Well, in my case, I new the last good kernel was *two* updates ago,
> so ORIG_HEAD wasn't the right thing to use.  I had to guess what
> to type instead of 'ORIG_HEAD'.

Well, instead of guessing, you can always do the safe thing, and just try, 
or just going far enough back to be really safe.

The "go far back" case is obviously wasteful, and if you go _too_ far 
back, you'll just spend a long time bisecting, but on the other hand, 
a binary search is pretty damned efficient, so even going back _way_ too 
far usually just results in a couple more bisection attempts.

But if you're unsure, before marking somethng "good", you can just test it 
out first, by doing something like

	git checkout -b test <version-to-test-here>

and compiling and testing that one. If it's good, you can just do a simple 
"git bisect good" to say that the current state was good..

Oh, and in general you don't ever have to name the good/bad ones: the 
example in Documentation/howto states that you should say

	git bisect bad master
	git bisect good ORIG_HEAD

but the fact is, whenever you leave off the version specifier, it will 
just assume that "current HEAD" is it. So quite often, a "git bisect" run 
will start with just a simple

	git bisect bad

to mark that the current head is bad (of course, that's 100% equivalent to 
saying "git bisect bad master" if you are on the master branch right 
then).

And if you don't remember what your last good kernel was, but you're sure 
that the last full release was good, you can just do

	git bisect good v2.6.15

and be done with it.

(Of course, right now there's 2075 commits in my git tree after 2.6.15, so 
that's a fair amount of bisecting.. But let's say that you had known more 
exactly, and been able to start off with just 300 commits - you only have 
to do three "bisect" runs to whittle the 2075 commits down to that range 
anyway - so it's not like you are totally screwed even if you don't know 
where the good one was).

> Which leads to one more question:  I have my kernel configured to
> add the -gxxxxxxxx localversion string to the kernel name.

Good man.

>						 I took
> a wild guess that the xxxxxxxx was the right thing to substitute
> for 'ORIG_HEAD' and I got lucky.

Yes. I guess we should document what the "-gxxxxx" thing means in the 
kernel, and that it's simply the short-hand git name for the top commit 
when the kernel was compiled. So you did exactly the right thing.

>			  But what about someone who
> doesn't know the magic 'xxxxxxxx' to use?  If I didn't know enough
> to keep a week's worth of daily kernel-builds with the 'xxxxxxxx'
> to guide me, would I still be able to do what I did today?

Yes. See above. It certainly takes you more effort, but it's not _hugely_ 
more effort.

> (For example, if this had been a 'git' bug instead of a kernel bug,
> I don't think I could have figured out how to use git-bisect to find
> the bug -- could I?)

Well, if you know how git works internally, it's actually fairly easy to 
do with any random project. You could, for example, just test whether 
git-1.0.6 was good first. Or, again, just use a sledge-hammer, and go for 
the original 1.0.

The alternative is to just ignore tagged versions altogether, and go by 
date. For example, you could do something like

	git log --since=1.week.ago

and just go to the end (right now, for me, that would be commit 8b32572, 
aka "git-init-db(1): Describe --shared and .."). Again, just do

	git checkout -b test 8b32572

and try that. If it was good, just mark it good and go from there. The 
test cycle for git is going to be a lot faster than the test cycle for the 
kernel, so you'll find any bug in no time.

		Linus