GIT bisection range errors

GIT bisection range errors

[Rene Herman]

Good day.

I'm in a git bisect and am experiencing strangeness. I did a

$ git checkout -b rc v2.6.26-rc1
$ git bisect start
$ git bisect bad
$ git bisect good v2.6.25

Yet, during this I'm finding myself at 2.6.25-rc6 and 2.6.25-rc8
as the last two results (both good...).

Here's the BISECT_LOG upto this point. Is there anyone available
who understands this well enough to be able to say from this that
my tree is fubar? It should be a straight Linus' clone, and it's
always pulling without trouble.

git-bisect start
# bad: [2ddcca36c8bcfa251724fe342c8327451988be0d] Linux 2.6.26-rc1
git-bisect bad 2ddcca36c8bcfa251724fe342c8327451988be0d
# good: [4b119e21d0c66c22e8ca03df05d9de623d0eb50f] Linux 2.6.25
git-bisect good 4b119e21d0c66c22e8ca03df05d9de623d0eb50f
# bad: [7ae44cfa7ab29b277691327e8de790d7b880722f] [ALSA] snd-powermac: style awacs.s and awacs.h
git-bisect bad 7ae44cfa7ab29b277691327e8de790d7b880722f
# good: [7cea51be4e91edad05bd834f3235b45c57783f0d] security: fix up documentation for security_module_enable
git-bisect good 7cea51be4e91edad05bd834f3235b45c57783f0d
# bad: [8f19ca1341a6d89bd96e2e69e6e10f46d3258089] x86: unify gfp masks
git-bisect bad 8f19ca1341a6d89bd96e2e69e6e10f46d3258089
# good: [f49e1aa133c2c9b74b5dfddca8863609bbda9086] [NETFILTER]: nf_conntrack_sip: update copyright
git-bisect good f49e1aa133c2c9b74b5dfddca8863609bbda9086
# good: [0b18542b7f5379e052d2a3132be91185776e7ceb] [NET]: Sink IPv6 menuoptions into its own submenu
git-bisect good 0b18542b7f5379e052d2a3132be91185776e7ceb


Rene.

Re: GIT bisection range errors

[Adrian Bunk]

On Fri, May 09, 2008 at 12:20:16AM +0200, Rene Herman wrote:
> Good day.
>
> I'm in a git bisect and am experiencing strangeness. I did a
>
> $ git checkout -b rc v2.6.26-rc1
> $ git bisect start
> $ git bisect bad
> $ git bisect good v2.6.25
>
> Yet, during this I'm finding myself at 2.6.25-rc6 and 2.6.25-rc8
> as the last two results (both good...).
>
> Here's the BISECT_LOG upto this point. Is there anyone available
> who understands this well enough to be able to say from this that
> my tree is fubar? It should be a straight Linus' clone, and it's
> always pulling without trouble.
>
> git-bisect start
> # bad: [2ddcca36c8bcfa251724fe342c8327451988be0d] Linux 2.6.26-rc1
> git-bisect bad 2ddcca36c8bcfa251724fe342c8327451988be0d
> # good: [4b119e21d0c66c22e8ca03df05d9de623d0eb50f] Linux 2.6.25
> git-bisect good 4b119e21d0c66c22e8ca03df05d9de623d0eb50f
> # bad: [7ae44cfa7ab29b277691327e8de790d7b880722f] [ALSA] snd-powermac: style awacs.s and awacs.h
> git-bisect bad 7ae44cfa7ab29b277691327e8de790d7b880722f
> # good: [7cea51be4e91edad05bd834f3235b45c57783f0d] security: fix up documentation for security_module_enable
> git-bisect good 7cea51be4e91edad05bd834f3235b45c57783f0d
> # bad: [8f19ca1341a6d89bd96e2e69e6e10f46d3258089] x86: unify gfp masks
> git-bisect bad 8f19ca1341a6d89bd96e2e69e6e10f46d3258089
> # good: [f49e1aa133c2c9b74b5dfddca8863609bbda9086] [NETFILTER]: nf_conntrack_sip: update copyright
> git-bisect good f49e1aa133c2c9b74b5dfddca8863609bbda9086
> # good: [0b18542b7f5379e052d2a3132be91185776e7ceb] [NET]: Sink IPv6 menuoptions into its own submenu
> git-bisect good 0b18542b7f5379e052d2a3132be91185776e7ceb

Don't trust any dates you see in git.  ;-)

The last commit in your list was added to David's tree at around the 
time Linus released Linux 2.6.25-rc7.

But David's tree was merged into Linus' tree after 2.6.25.

So actually everything is fine.

> Rene.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: GIT bisection range errors

[Rene Herman]

On 09-05-08 00:25, Adrian Bunk wrote:
> On Fri, May 09, 2008 at 12:20:16AM +0200, Rene Herman wrote:
>> Good day.
>>
>> I'm in a git bisect and am experiencing strangeness. I did a
>>
>> $ git checkout -b rc v2.6.26-rc1
>> $ git bisect start
>> $ git bisect bad
>> $ git bisect good v2.6.25
>>
>> Yet, during this I'm finding myself at 2.6.25-rc6 and 2.6.25-rc8
>> as the last two results (both good...).
>>
>> Here's the BISECT_LOG upto this point. Is there anyone available
>> who understands this well enough to be able to say from this that
>> my tree is fubar? It should be a straight Linus' clone, and it's
>> always pulling without trouble.
>>
>> git-bisect start
>> # bad: [2ddcca36c8bcfa251724fe342c8327451988be0d] Linux 2.6.26-rc1
>> git-bisect bad 2ddcca36c8bcfa251724fe342c8327451988be0d
>> # good: [4b119e21d0c66c22e8ca03df05d9de623d0eb50f] Linux 2.6.25
>> git-bisect good 4b119e21d0c66c22e8ca03df05d9de623d0eb50f
>> # bad: [7ae44cfa7ab29b277691327e8de790d7b880722f] [ALSA] snd-powermac: style awacs.s and awacs.h
>> git-bisect bad 7ae44cfa7ab29b277691327e8de790d7b880722f
>> # good: [7cea51be4e91edad05bd834f3235b45c57783f0d] security: fix up documentation for security_module_enable
>> git-bisect good 7cea51be4e91edad05bd834f3235b45c57783f0d
>> # bad: [8f19ca1341a6d89bd96e2e69e6e10f46d3258089] x86: unify gfp masks
>> git-bisect bad 8f19ca1341a6d89bd96e2e69e6e10f46d3258089
>> # good: [f49e1aa133c2c9b74b5dfddca8863609bbda9086] [NETFILTER]: nf_conntrack_sip: update copyright
>> git-bisect good f49e1aa133c2c9b74b5dfddca8863609bbda9086
>> # good: [0b18542b7f5379e052d2a3132be91185776e7ceb] [NET]: Sink IPv6 menuoptions into its own submenu
>> git-bisect good 0b18542b7f5379e052d2a3132be91185776e7ceb
> 
> Don't trust any dates you see in git.  ;-)
> 
> The last commit in your list was added to David's tree at around the 
> time Linus released Linux 2.6.25-rc7.
> 
> But David's tree was merged into Linus' tree after 2.6.25.
> 
> So actually everything is fine.

Well, thanks for the reply and I'm going forward for now, but the Makefile
is actually calling this 2.6.25-rc8. My next "git bisect good" after the
above landed me now after 2.6.25 according to the Makefile. It could just
be a tags issue I guess, where my tree is confused about what tag belongs
to v2.6.25?

(new two lines in the log)

# good: [ba380013b681e91e059f95b51002f8d43024b371] b43: Add fastpath to b43_mac_suspend()
git-bisect good ba380013b681e91e059f95b51002f8d43024b371

Rene.

Re: GIT bisection range errors

[Ken Moffat]

On Fri, May 09, 2008 at 12:36:55AM +0200, Rene Herman wrote:
> On 09-05-08 00:25, Adrian Bunk wrote:
> >On Fri, May 09, 2008 at 12:20:16AM +0200, Rene Herman wrote:
> >>Good day.
> >>
> >>I'm in a git bisect and am experiencing strangeness. I did a
> >>
> >>$ git checkout -b rc v2.6.26-rc1
> >>$ git bisect start
> >>$ git bisect bad
> >>$ git bisect good v2.6.25
> >>
> >>Yet, during this I'm finding myself at 2.6.25-rc6 and 2.6.25-rc8
> >>as the last two results (both good...).
> >>
> >>Here's the BISECT_LOG upto this point. Is there anyone available
> >>who understands this well enough to be able to say from this that
> >>my tree is fubar? It should be a straight Linus' clone, and it's
> >>always pulling without trouble.
> >>
> >>git-bisect start
> >># bad: [2ddcca36c8bcfa251724fe342c8327451988be0d] Linux 2.6.26-rc1
> >>git-bisect bad 2ddcca36c8bcfa251724fe342c8327451988be0d
> >># good: [4b119e21d0c66c22e8ca03df05d9de623d0eb50f] Linux 2.6.25
> >>git-bisect good 4b119e21d0c66c22e8ca03df05d9de623d0eb50f
> >># bad: [7ae44cfa7ab29b277691327e8de790d7b880722f] [ALSA] snd-powermac: 
> >>style awacs.s and awacs.h
> >>git-bisect bad 7ae44cfa7ab29b277691327e8de790d7b880722f
> >># good: [7cea51be4e91edad05bd834f3235b45c57783f0d] security: fix up 
> >>documentation for security_module_enable
> >>git-bisect good 7cea51be4e91edad05bd834f3235b45c57783f0d
> >># bad: [8f19ca1341a6d89bd96e2e69e6e10f46d3258089] x86: unify gfp masks
> >>git-bisect bad 8f19ca1341a6d89bd96e2e69e6e10f46d3258089
> >># good: [f49e1aa133c2c9b74b5dfddca8863609bbda9086] [NETFILTER]: 
> >>nf_conntrack_sip: update copyright
> >>git-bisect good f49e1aa133c2c9b74b5dfddca8863609bbda9086
> >># good: [0b18542b7f5379e052d2a3132be91185776e7ceb] [NET]: Sink IPv6 
> >>menuoptions into its own submenu
> >>git-bisect good 0b18542b7f5379e052d2a3132be91185776e7ceb
> >
> >Don't trust any dates you see in git.  ;-)
> >
> >The last commit in your list was added to David's tree at around the 
> >time Linus released Linux 2.6.25-rc7.
> >
> >But David's tree was merged into Linus' tree after 2.6.25.
> >
> >So actually everything is fine.
> 
> Well, thanks for the reply and I'm going forward for now, but the Makefile
> is actually calling this 2.6.25-rc8. My next "git bisect good" after the
> above landed me now after 2.6.25 according to the Makefile. It could just
> be a tags issue I guess, where my tree is confused about what tag belongs
> to v2.6.25?
> 
> (new two lines in the log)
> 
> # good: [ba380013b681e91e059f95b51002f8d43024b371] b43: Add fastpath to 
> b43_mac_suspend()
> git-bisect good ba380013b681e91e059f95b51002f8d43024b371
> 
> Rene.
 I reported a similar thing at the beginning of April
http://lkml.org/lkml/2008/4/2/390 - 2.6.25-rc1 bad, 2.6.24 good, git
dropped me back at 2.6.24-rc4 (again, according to the top level
Makefile).

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

Re: GIT bisection range errors

[Roland Dreier]

 > > $ git checkout -b rc v2.6.26-rc1
 > > $ git bisect start
 > > $ git bisect bad
 > > $ git bisect good v2.6.25
 > >
 > > Yet, during this I'm finding myself at 2.6.25-rc6 and 2.6.25-rc8
 > > as the last two results (both good...).

 >  I reported a similar thing at the beginning of April
 > http://lkml.org/lkml/2008/4/2/390 - 2.6.25-rc1 bad, 2.6.24 good, git
 > dropped me back at 2.6.24-rc4 (again, according to the top level
 > Makefile).

This is normal and expected, due to the distributed nature of git and
the fact that git-bisect operates on the full topology of history and
not just a linear sequence of commits.

Imagine history like:

    A---B---C---D
     \         /
      \       /
       \     /
        E---F

where B is good and D is bad.  Now, when you bisect, there is no way to
know whether, say, E is good or bad and hence the bisect process may
present E as a tree to try.

Now, if B is the 2.6.25 release, then since E branched off before B, it
will have a Makefile that says 2.6.25-rcX.  Which is exactly the
behavior you are seeing.

In short, everything looks fine and is behaving as expected.

 - R.

Re: GIT bisection range errors

[Rene Herman]

On 09-05-08 01:33, Roland Dreier wrote:

> This is normal and expected, due to the distributed nature of git and
> the fact that git-bisect operates on the full topology of history and
> not just a linear sequence of commits.
> 
> Imagine history like:
> 
>     A---B---C---D
>      \         /
>       \       /
>        \     /
>         E---F
> 
> where B is good and D is bad.  Now, when you bisect, there is no way to
> know whether, say, E is good or bad and hence the bisect process may
> present E as a tree to try.
> 
> Now, if B is the 2.6.25 release, then since E branched off before B, it
> will have a Makefile that says 2.6.25-rcX.  Which is exactly the
> behavior you are seeing.
> 
> In short, everything looks fine and is behaving as expected.

Great explanation. Thanks.

Rene

Re: GIT bisection range errors

[Ken Moffat]

On Thu, May 08, 2008 at 04:33:04PM -0700, Roland Dreier wrote:
>  > > $ git checkout -b rc v2.6.26-rc1
>  > > $ git bisect start
>  > > $ git bisect bad
>  > > $ git bisect good v2.6.25
>  > >
>  > > Yet, during this I'm finding myself at 2.6.25-rc6 and 2.6.25-rc8
>  > > as the last two results (both good...).
> 
>  >  I reported a similar thing at the beginning of April
>  > http://lkml.org/lkml/2008/4/2/390 - 2.6.25-rc1 bad, 2.6.24 good, git
>  > dropped me back at 2.6.24-rc4 (again, according to the top level
>  > Makefile).
> 
> This is normal and expected, due to the distributed nature of git and
> the fact that git-bisect operates on the full topology of history and
> not just a linear sequence of commits.
> 
> Imagine history like:
> 
>     A---B---C---D
>      \         /
>       \       /
>        \     /
>         E---F
> 
> where B is good and D is bad.  Now, when you bisect, there is no way to
> know whether, say, E is good or bad and hence the bisect process may
> present E as a tree to try.
> 
> Now, if B is the 2.6.25 release, then since E branched off before B, it
> will have a Makefile that says 2.6.25-rcX.  Which is exactly the
> behavior you are seeing.
> 
> In short, everything looks fine and is behaving as expected.
> 
>  - R.

 But, surely those of us who bisect against linus' tree only
care about the commits which made it into his tree, and in the
context of whatever else was in _his_ tree at the time ?

 Maybe I'm under a misapprehension about changesets and merges.  I
thought a merge was just pulling in a series of changesets, and that
each changeset only contains related items (comment, changed lines,
added files, deleted files).

 Whatever else may be in tree E, I don't expect it to have a commit
which changes $EXTRAVERSION, purely because tree E is not Linus'
tree.  To me, that field is somewhat special - it indicates where I am
(e.g. if bisecting across multiple rcs, or even across multiple
releases) and it determines where the modules will go.

 I see from Linus' reply to the original mail that this is indeed
normal.  That certainly isn't the word I would choose to use : we
give things names to describe them and in this case the EXTRAVERSION
appears to inhabit a parrallel universe to the pre-existing usage
of "2.6.24 good, 2.6.25-rc1 bad".   Colour me more confused than ever.

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

Re: GIT bisection range errors

[Daniel Barkalow]

On Fri, 9 May 2008, Ken Moffat wrote:

> On Thu, May 08, 2008 at 04:33:04PM -0700, Roland Dreier wrote:
> >  > > $ git checkout -b rc v2.6.26-rc1
> >  > > $ git bisect start
> >  > > $ git bisect bad
> >  > > $ git bisect good v2.6.25
> >  > >
> >  > > Yet, during this I'm finding myself at 2.6.25-rc6 and 2.6.25-rc8
> >  > > as the last two results (both good...).
> > 
> >  >  I reported a similar thing at the beginning of April
> >  > http://lkml.org/lkml/2008/4/2/390 - 2.6.25-rc1 bad, 2.6.24 good, git
> >  > dropped me back at 2.6.24-rc4 (again, according to the top level
> >  > Makefile).
> > 
> > This is normal and expected, due to the distributed nature of git and
> > the fact that git-bisect operates on the full topology of history and
> > not just a linear sequence of commits.
> > 
> > Imagine history like:
> > 
> >     A---B---C---D
> >      \         /
> >       \       /
> >        \     /
> >         E---F
> > 
> > where B is good and D is bad.  Now, when you bisect, there is no way to
> > know whether, say, E is good or bad and hence the bisect process may
> > present E as a tree to try.
> > 
> > Now, if B is the 2.6.25 release, then since E branched off before B, it
> > will have a Makefile that says 2.6.25-rcX.  Which is exactly the
> > behavior you are seeing.
> > 
> > In short, everything looks fine and is behaving as expected.
> > 
> >  - R.
> 
>  But, surely those of us who bisect against linus' tree only
> care about the commits which made it into his tree, and in the
> context of whatever else was in _his_ tree at the time ?
> 
>  Maybe I'm under a misapprehension about changesets and merges.  I
> thought a merge was just pulling in a series of changesets, and that
> each changeset only contains related items (comment, changed lines,
> added files, deleted files).

No, git tracks states and where they came from, not changes per se. That 
is, when you look at a commit by David Miller, you're looking at exactly 
the file contents that David Miller had when making the commit. Some other 
systems linearize history such that what you'd see in Linus's tree is what 
David Miller would have had if he'd made his changes to the tree Linus had 
before merging David's branch, but that's not the normal thing to do with 
git in this case.

>  Whatever else may be in tree E, I don't expect it to have a commit
> which changes $EXTRAVERSION, purely because tree E is not Linus'
> tree.  To me, that field is somewhat special - it indicates where I am
> (e.g. if bisecting across multiple rcs, or even across multiple
> releases) and it determines where the modules will go.

Tree E doesn't change versions; it's got the same version as A. But C and 
D pick up the version change from B, which means that C and E have 
different versions. You could also look at it like this: going back from D 
to F changes the version, not because anybody on the lower path changed 
it, but because Linus included the version change from his own side when 
doing the merge.

>  I see from Linus' reply to the original mail that this is indeed
> normal.  That certainly isn't the word I would choose to use : we
> give things names to describe them and in this case the EXTRAVERSION
> appears to inhabit a parrallel universe to the pre-existing usage
> of "2.6.24 good, 2.6.25-rc1 bad".   Colour me more confused than ever.

2.6.26-rc1 is bad, 2.6.25 is good, vanilla 2.6.25-rc1 is good, but some 
modified version of 2.6.25-rc1 was bad. It's like if you take 2.6.25, and 
you leave the Makefile the same but change some driver. You can find that 
your 2.6.25 is now broken, while the original 2.6.25 is not. What's going 
on in this bisect run is that Rene's seeing this same situation, but from 
the perspective of looking back from the future and looking at somebody 
else's state.

	-Daniel
*This .sig left intentionally blank*

Re: GIT bisection range errors

[Ken Moffat]

On Fri, May 09, 2008 at 05:45:00PM -0400, Daniel Barkalow wrote:
> On Fri, 9 May 2008, Ken Moffat wrote:
> 
> > 
> >  But, surely those of us who bisect against linus' tree only
> > care about the commits which made it into his tree, and in the
> > context of whatever else was in _his_ tree at the time ?
> > 
> >  Maybe I'm under a misapprehension about changesets and merges.  I
> > thought a merge was just pulling in a series of changesets, and that
> > each changeset only contains related items (comment, changed lines,
> > added files, deleted files).
> 
> No, git tracks states and where they came from, not changes per se. That 
> is, when you look at a commit by David Miller, you're looking at exactly 
> the file contents that David Miller had when making the commit. Some other 
> systems linearize history such that what you'd see in Linus's tree is what 
> David Miller would have had if he'd made his changes to the tree Linus had 
> before merging David's branch, but that's not the normal thing to do with 
> git in this case.

 That was the root cause of my misunderstanding - I thought it was
tracking the changes themselves.
> 
> >  Whatever else may be in tree E, I don't expect it to have a commit
> > which changes $EXTRAVERSION, purely because tree E is not Linus'
> > tree.  To me, that field is somewhat special - it indicates where I am
> > (e.g. if bisecting across multiple rcs, or even across multiple
> > releases) and it determines where the modules will go.
> 
> Tree E doesn't change versions; it's got the same version as A. But C and 
> D pick up the version change from B, which means that C and E have 
> different versions. You could also look at it like this: going back from D 
> to F changes the version, not because anybody on the lower path changed 
> it, but because Linus included the version change from his own side when 
> doing the merge.
> 
 OK, I think I understand that now.

> >  I see from Linus' reply to the original mail that this is indeed
> > normal.  That certainly isn't the word I would choose to use : we
> > give things names to describe them and in this case the EXTRAVERSION
> > appears to inhabit a parrallel universe to the pre-existing usage
> > of "2.6.24 good, 2.6.25-rc1 bad".   Colour me more confused than ever.
> 
> 2.6.26-rc1 is bad, 2.6.25 is good, vanilla 2.6.25-rc1 is good, but some 
> modified version of 2.6.25-rc1 was bad. It's like if you take 2.6.25, and 
> you leave the Makefile the same but change some driver. You can find that 
> your 2.6.25 is now broken, while the original 2.6.25 is not. What's going 
> on in this bisect run is that Rene's seeing this same situation, but from 
> the perspective of looking back from the future and looking at somebody 
> else's state.
> 
 Many thanks for taking the time to explain this in detail!

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

Re: GIT bisection range errors

[Linus Torvalds]

On Fri, 9 May 2008, Rene Herman wrote:
> 
> I'm in a git bisect and am experiencing strangeness. I did a
> 
> $ git checkout -b rc v2.6.26-rc1
> $ git bisect start
> $ git bisect bad
> $ git bisect good v2.6.25
> 
> Yet, during this I'm finding myself at 2.6.25-rc6 and 2.6.25-rc8
> as the last two results (both good...).

This is very normal.

Why?

Because a lot (in fact, *most*) of the code that was merged after v2.6.25 
was released was actually *written* and committed long before v2.6.25.

It just got merged into my tree much later.

So what happens? The bisection run starts walking into all that history, 
and that history is *not* based on the released v2.6.25 at all, it's based 
on much earlier kernels (eg the -rc kernels).

So what you see is perfectly normal and expected. It's only unexpected if 
you think of history as a linear thing, but it isn't - it's full of 
merging of code that was branched off from (much) earlier code points.

		Linus

Re: GIT bisection range errors

[Rene Herman]

On 09-05-08 01:00, Linus Torvalds wrote:

> On Fri, 9 May 2008, Rene Herman wrote:

>> I'm in a git bisect and am experiencing strangeness. I did a
>>
>> $ git checkout -b rc v2.6.26-rc1
>> $ git bisect start
>> $ git bisect bad
>> $ git bisect good v2.6.25
>>
>> Yet, during this I'm finding myself at 2.6.25-rc6 and 2.6.25-rc8
>> as the last two results (both good...).
> 
> This is very normal.
> 
> Why?
> 
> Because a lot (in fact, *most*) of the code that was merged after v2.6.25 
> was released was actually *written* and committed long before v2.6.25.
> 
> It just got merged into my tree much later.
> 
> So what happens? The bisection run starts walking into all that history, 
> and that history is *not* based on the released v2.6.25 at all, it's based 
> on much earlier kernels (eg the -rc kernels).
> 
> So what you see is perfectly normal and expected. It's only unexpected if 
> you think of history as a linear thing, but it isn't - it's full of 
> merging of code that was branched off from (much) earlier code points.

Ah. Yes, that needs a bit of thought re-warping, but I guess that makes sense.

Thanks much, was afraid I needed to rebuild my local tree.

Rene.