Re: GIT bisection range errors

From: Ken Moffat
Date: Sat May 10 2008 - 12:53:16 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/