[lkml]   [2008]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT pull] x86 fixes for 2.6.26
    2008/5/17 Linus Torvalds <>:
    > On Fri, 16 May 2008, Theodore Tso wrote:
    >> Why do you consider rebasing topic branches a bad thing?
    > Rebasing branches is absolutely not a bad thing for individual developers.
    > But it *is* a bad thing for a subsystem maintainer.
    <snip very nice description of when to use rebase>
    > BUT if you're a subsystem maintainer, and other people are supposed to be
    > able to pull from you, and you're supposed to merge other peoples work,
    > then rebasing is a *horrible* workflow.
    <snip stuff on fetch + merge>
    > In other words, I very heavily would suggest that subsystem maintainers -
    > at least of the bigger subsystems, really see themselves as being in the
    > same situation I am: rather than doing the work, trying to make it easy
    > for *others* to do the work, and then just pulling the result.


    Thank you for some very good descriptions on proper git workflow. That
    was very informative.

    As new Trivial tree maintainer I'm trying to figure out how I should
    manage that tree, and based on your description on git use I have a
    few questions.

    What I did for my first merge-window was simply clone your tree,
    create a for-linus branch, add all the patches to that branch and ask
    you to pull. That worked nicely that once, but I guess that wiping the
    tree and starting from a fresh clone every merge window wouldn't be a
    good idea - especially since I'd like Trivial to also get pulled into

    This is what I think I should be doing going forward. I'd appreciate
    it if you could comment on whether or not it's the right way to do

    Start off with a clone of your tree (master branch).

    Pull your tree into 'master' daily (or at least often).

    Create a for-linux-2.6.27 branch or the upcomming 2.6.27 merge window
    and apply all the patches I currently have pendng in a mailbox to that
    branch. Keep the branch reasonably up-to-date by doing a weekly git
    fetch + merge from my 'master' branch that tracks your tree.

    Once the 2.6.27 merge window opens, ask you to pull the
    'for-linux-2.6.27' branch and once you have done so, leave that branch
    alone forever.

    Branch off a new 'for-linux-2.6.28' branch and repeat.

    As for linux-next, I'd create a 'linux-next' branch that I would
    update whenever I change one of the 'for-linux-2.6.xx' branches, by
    doing a fetch from the branch into 'linux-next' and then a merge.

    Does that sound sane or is there a better way?

    Jesper Juhl <>
    Don't top-post
    Plain text mails only, please

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