lkml.org 
[lkml]   [2008]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2008-05-10 18:55    [W:0.024 / U:58.656 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site