[lkml]   [2008]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Announce: Linux-next (Or Andrew's dream :-))
    From: James Bottomley <>
    Date: Tue, 12 Feb 2008 12:24:42 -0600

    > Hm ... I think net is a counter example to this. Rebases certainly work
    > for them. The issue, I thought, was around the policy of rebasing and
    > how often.
    > I see the question as being one of who creates the history. When
    > something goes into your tree, that's an obvious history point and we
    > can't rewrite it. However, when something goes into my trees, I don't
    > think it's as obviously a history point that has to be preserved, so I
    > can rebase obviously, rebasing causes disruption, so I don't do it
    > unless it's necessitated by an actual conflict.

    And I realize that regrettably I end up rebasing a lot.

    Let's say that today I merge a TCP bug fix into Linus's 2.6.24-rcX
    tree. When I have the net-2.6.25 tree going I know that this is going
    to create merge conflicts with the 80 or so odd TCP patches I have in

    Nobody can pull net-2.6.25 into Linus upstream without having to sift
    through the merging of that stuff. It never merges cleanly using
    the automated mechanisms, because since the changes are split up
    nicely there are long changeset dependency chains.

    So I rebase, and do the merging work by hand.

    Next, let's say Jeff merges some net driver bug fixes into upstream,
    resulting in potential conflicts with the several hundred or so driver
    changes that are in the net-2.6.25 tree too.

    In fact near the end of 2.6.24 development, there was a new merge
    conflict created on a daily basis with the net-2.6.25 tree. You
    simply cannot avoid this when you're managing 1500+ changes.

    I even had to rebase the net-2.6.25 tree once or twice in Australia as
    the merge window was openning up because I could push something
    cleanly to Linus. There were conflicts created by stuff that got in
    before the net-2.6.25 tree, mostly in files like the feature removal
    schedule, Kconfig files, and whatnot.

    At times I even felt the urge to avoid merging a bug fix upstream
    because of all the merge conflicts it would create, but I of course
    can't and won't do that. 8)

    It actually turns out that things simplify once a tree gets into the
    -stable folks hands. I pick out bug fixes as they go upstream, and
    toss it to them once Linus sucks it in and I have an upstream
    changeset ID to give them. I don't have to worry about -stable
    changesets causing development merge grief later on.

    And I've also yet to be shown how to completely remove a changeset
    from a GIT tree without rebasing :-)

     \ /
      Last update: 2008-02-13 01:31    [W:0.022 / U:18.792 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site