git bisect goes wild?

git bisect goes wild?

[Jan Kara]

  Hi,

  I've been bisecting some change in Linux kernel. The output of
"git bisect log" is:
git-bisect start
# good: [bbf25010f1a6b761914430f5fca081ec8c7accd1] Linux 2.6.23
git-bisect good bbf25010f1a6b761914430f5fca081ec8c7accd1
# bad: [49914084e797530d9baaf51df9eda77babc98fa8] Linux 2.6.24
git-bisect bad 49914084e797530d9baaf51df9eda77babc98fa8
# bad: [fe071d7e8aae5745c009c808bb8933f22a9e305a] oom: add
# oom_kill_allocating_task sysctl
git-bisect bad fe071d7e8aae5745c009c808bb8933f22a9e305a
# good: [117494a1b65183f0e3fcc817b07944bc5c465050] Merge
# master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6
git-bisect good 117494a1b65183f0e3fcc817b07944bc5c465050
# bad: [419217cb1d0266f62cbea6cdc6b1d1324350bc34] Merge branch
# 'v2.6.24-lockdep' of
# git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-lockdep
git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34
# good: [c8c55bcb43d790d97790cfa319d80045a71fde39] Merge
# git://git.infradead.org/mtd-2.6
git-bisect good c8c55bcb43d790d97790cfa319d80045a71fde39
# good: [3e9830dcabdeb3656855ec1b678b6bcf3b50261c] sched: run
# sched_domain_debug() if CONFIG_SCHED_DEBUG=y
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 come? git version is 1.5.6.
  Thanks for any suggestions.

								Honza

PS: Please CC me since I'm not on the list.
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: git bisect goes wild?

[Peter Harris]

2009/2/24 Jan Kara:
>  Hi,
>
>  I've been bisecting some change in Linux kernel. The output of
> "git bisect log" is:
...
> git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34
...
> 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.

Peter Harris

Re: git bisect goes wild?

[Jan Kara]

On Tue 24-02-09 13:59:16, Peter Harris wrote:
> 2009/2/24 Jan Kara:
> >  Hi,
> >
> >  I've been bisecting some change in Linux kernel. The output of
> > "git bisect log" is:
> ...
> > git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34
> ...
> > 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.

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: git bisect goes wild?

[Teemu Likonen]

On 2009-02-24 20:10 (+0100), Jan Kara wrote:

>   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.

Maybe this explanation helps:

http://thread.gmane.org/gmane.comp.version-control.git/99967/focus=99977

Re: git bisect goes wild?

[Jan Kara]

On Tue 24-02-09 21:14:12, Teemu Likonen wrote:
> On 2009-02-24 20:10 (+0100), Jan Kara wrote:
> 
> >   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.
> 
> Maybe this explanation helps:
> 
> http://thread.gmane.org/gmane.comp.version-control.git/99967/focus=99977
  OK, thanks for the pointer. I'll trust that the result will be sensible
:).

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: git bisect goes wild?

[Daniel Barkalow]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1994 bytes --]

On Tue, 24 Feb 2009, Jan Kara wrote:

> On Tue 24-02-09 13:59:16, Peter Harris wrote:
> > 2009/2/24 Jan Kara:
> > >  Hi,
> > >
> > >  I've been bisecting some change in Linux kernel. The output of
> > > "git bisect log" is:
> > ...
> > > git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34
> > ...
> > > 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.

	-Daniel
*This .sig left intentionally blank*

Re: git bisect goes wild?

[Jan Kara]

On Tue 24-02-09 14:46:09, Daniel Barkalow wrote:
> On Tue, 24 Feb 2009, Jan Kara wrote:
> 
> > On Tue 24-02-09 13:59:16, Peter Harris wrote:
> > > 2009/2/24 Jan Kara:
> > > >  Hi,
> > > >
> > > >  I've been bisecting some change in Linux kernel. The output of
> > > > "git bisect log" is:
> > > ...
> > > > git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34
> > > ...
> > > > 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...
  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.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: git bisect goes wild?

[Daniel Barkalow]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4073 bytes --]

On Tue, 24 Feb 2009, Jan Kara wrote:

> On Tue 24-02-09 14:46:09, Daniel Barkalow wrote:
> > On Tue, 24 Feb 2009, Jan Kara wrote:
> > 
> > > On Tue 24-02-09 13:59:16, Peter Harris wrote:
> > > > 2009/2/24 Jan Kara:
> > > > >  Hi,
> > > > >
> > > > >  I've been bisecting some change in Linux kernel. The output of
> > > > > "git bisect log" is:
> > > > ...
> > > > > git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34
> > > > ...
> > > > > 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*