Re: git bisect goes wild?

On Tue, 24 Feb 2009, Jan Kara wrote:

On Tue 24-02-09 14:46:09, Daniel Barkalow wrote:

quoted

On Tue, 24 Feb 2009, Jan Kara wrote:

quoted

On Tue 24-02-09 13:59:16, Peter Harris wrote:

quoted

2009/2/24 Jan Kara:

quoted

 Hi,

 I've been bisecting some change in Linux kernel. The output of
"git bisect log" is:

...

quoted

git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34

...

quoted

git-bisect good 3e9830dcabdeb3656855ec1b678b6bcf3b50261c

 But after the last command, I was sent to commit
9ec76fbf7d6da3e98070a7059699d0ca019b0c9b which is far outside the window
between the last good and bad commit.

How did you determine that this commit is outside the window?

When I run "gitk 3e9830..419217" it shows that commit, as does "git
log". 9ec76fb appears to be inside the window to me.

  Ho, hum, right. But if I do:
git describe 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b
  I get v2.6.23-rc3-215-g9ec76fb which is a bit strange for bisecting
between 2.6.23 and 2.6.24. Also the kernel gets named 2.6.23-rc3 and kernel
config options get also to some pre 2.6.23 state. That's what is confusing
me. It seems like the kernel checked out is some old one. I'm not a git
expert so it might be fine but it just seems really strange.

If you're trying to find a problem that got into the mainline kernel 
between 2.6.23 and 2.6.24, you should expect to find a change that was 
added less than 2 weeks after 2.6.23 was released, and written before 
2.6.23 was released. Such a change would probably have been written 
against a mainline kernel somewhere in the 2.6.23-rcN range. So the 
description you should expect of the version that introduces the bug is 
"2.6.23-rcN with some patches that hadn't been merged to mainline".

In order for your bisect to end up with a commit that looks like it's 
between 2.6.23 and 2.6.24, Linus would have to have merged a buggy commit 
for 2.6.24 written after 2.6.23 was released, which is against how things 
are supposed to be done.

  Yes, thanks for explanation. I've figured it out as well after reading
the posted link. What makes me a bit afraid is that bugs (or especially
performance regression, which is what I'm hunting right now) can be caused
by interference of two independent changes. I.e., in a situation like:
  A-B-C-D
   \_E_/

  if I start bisecting between B and D and the problem happens only when
both C and E are merged, then the best what I can end up with is that the
merge-commit is what causes the regression, isn't it? Which is sometimes
useless when the merge commit is a merge of some branch with 1000
patches...

You'll end up with it blaming D, yes.

  So it might be useful if git-bisect had a "linear" mode - we would first
create a linear history of commits and then bisect in it. Now I understand
that this is not always possible (sometimes changes would not apply) but it
should be possible when merges are trivial (i.e., all commits apply cleanly
to the source just before the merge commit - and this is quite often the
case at least with the Linux kernel). Just my 2 cents.

Linearizing wouldn't really give entirely accurate results for bisecting a 
combination; you would get one of the sides where the problem starts, but 
you wouldn't know what it conflicts with. The ideal thing would actually 
be to first find that some particular merge is bad, and then bisect each 
side individually, looking for the first commit on each side that, when 
they're merged together, produces a result with the problem. In any case, 
doing much more complicated than the current bisect requires being able to 
automate a complicated sequence of operations (going back to the user at 
certain points, because it may be necessary to do a manual merge to test), 
which hasn't been made practical yet.

	-Daniel
*This .sig left intentionally blank*