lkml.org 
[lkml]   [2008]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT pull] x86 fixes for 2.6.26
    2008/5/17 Linus Torvalds <torvalds@linux-foundation.org>:
    >
    >
    > 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.
    >

    Linus,

    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
    linux-next.

    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
    things.

    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 <jesper.juhl@gmail.com>
    Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
    Plain text mails only, please http://www.expita.com/nomime.html


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