Messages in this thread | | | Date | Sat, 10 May 2008 17:52:21 +0100 | From | Ken Moffat <> | Subject | Re: GIT bisection range errors |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |