lkml.org 
[lkml]   [2010]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [GIT PULL] block/IO bits for 2.6.36-rc1
    On Sat, Aug 7, 2010 at 12:34 AM, Jens Axboe <jaxboe@fusionio.com> wrote:
    >
    > OK, so a question on this. Say a bug surfaces in the middle of the
    > release and we push in a change to fix that at 2.6.36-rc3 time. This
    > same patch will not apply directly to the branch holding 2.6.37 patches
    > due to code reshuffling or whatnot. How do you want that handled? I
    > can't pull in your branch and resolve it. The merge conflict may not be
    > visible to you until 2.6.36 is released and I want to offload the
    > patches to you, but it will be visible in linux-next pretty much
    > immediately.

    So I think there's a few possible answers to that.

    One is the one I outlined in my previous email: merge the next -rc
    tag, and explain why you merged it in the commit message. That not
    only makes the merge commit message be way more informative ("Merge
    commit v2.6.3x-rcy" rather than "Merge branch 'master'"), but it also
    automatically acts as a "rate limiter" for the merges.

    Now, that may cause problems for linux-next for a few days too, since
    I think linux-next always starts from some random tree-of-the-day of
    mine. That itself may be more indicative of a linux-next problem,
    though. It might well make sense to base linux-next itself on the
    latest tagged release rather than on some random daily thing (and if
    the things that get merged _into_ linux-next then are based on a
    random daily thing and bring linux-next forward, then that's a problem
    with the trees getting merged - they shouldn't be doing that either).

    The other possibility is for you to do throw-away merges just for
    linux-next. That way _you_ do the merge (not Stephen or one of the
    linux-next helpers), but the merge is going only into for-next, not
    into your for-2.6.36 branch. "git rerere" will help you re-do the same
    merge for future for-next trees - the same way linux-next already
    generally only needs to do the merge resolution once.

    Then, when you actually want to send it to me, at that point (if it's
    a really complicated merge and you know it's too complex for me), you
    can do one final merge into 'for-linus' before you send me the pull
    request. Again, git rerere will help you re-use your previous merge
    resolutions.

    Or don't merge at all when you send it to me, and only do the merge if
    I then reply with "ok, that's too complicated for me".

    I will _never_ complain about you sending me something I can't merge.
    I may throw it back at you, but I won't complain about you trying to
    give me merge work. I really do like knowing about the conflicts.

    Of course, if I do the merge conflict resolution I may then see
    something odd and complain about it. Something I might not have even
    noticed if it hadn't been pointed out to me by the conflict ;)

    Linus


    \
     
     \ /
      Last update: 2010-08-07 23:17    [W:0.023 / U:0.668 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site