[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

    On Sun, 18 May 2008, Jesper Juhl wrote:
    > 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.

    Well, I actually suspect that especially for the trivial tree, that may
    not actually be a horribly bad workflow.

    The whole "fresh clone + a bunch of patches" is yet another different way
    of using git, but it's a totally valid one: it uses git as just another
    way to send a patch-series, with the added advantage that the base of that
    patch-series is explicit in the result.

    (You can do that with quilt too, I think. Or at least with the scripts
    Andrew does - I think you can tell him what the base point for a series
    is. But when merging to me, git is obviously the way to go).

    So for something that pretty fundamentally is literally just a series of
    random patches, I don't think the workflow of just staging them as a
    series on top of some known-good git tree is the wrong one. It's not like
    the Trivial tree is likely to be something that would have much use of git
    as a distributed model (iow - I think the trivial patches are actually
    better off seen as a patch-queue than having merges and other things in

    That said, re-cloning every time is obviously pretty wasteful. There are
    better ways to track a git tree, notably it's likely best to just clone
    once and then just keep that one up-to-date. But the difference between
    that and just re-cloning is really not that huge - technically you'd end
    up doing the exact same thing and have the exact same tree, just two
    different ways to do it.

    So your alternate approach:

    > Start off with a clone of your tree (master branch).
    > Pull your tree into 'master' daily (or at least often).

    So doing daily pull's is what I generally do *not* want people to do, but
    if you have a pristine tree and haven't done any development of your own,
    then the "pull" is obviously not going to do anything but keep the tree
    fresh, so in this special case it's fine.

    So you'd not be merging, you'd be just refreshing your clone - and in that
    sense this is 100% equivalent to just re-cloning all the time.

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

    So generally, I'd suggest against this "keep it fresh". In many ways it
    just makes things harder (if only because bisection of your series will no
    longer be a nice linear run, but also because the history will actually be
    harder to read), and if the merges are just weekly regular merges, then
    the purpose of them isn't even very clear.

    So I'd literally suggest doing merges primarily only

    - at release points (now the purpose is clear; you're merging a very
    specific state, not just some random point).

    But even this one should generally be done only if there is some real
    reason for it (ie you're really quite far behind), and

    - or if you actually see a merge conflict, and you want to handle the
    conflict so that I won't have to.

    But I'll actually happily handle trivial merges too, so this is by no
    means even a requirement - if the merge ends up being non-trivial, I'll
    let people know anyway and either say "ok, that's so complicated, and I
    don't know the area well enough, so can you please do it for me", or
    say "ok, I merged it, but can you please double-check the result".

    Quite frankly, if you actually do your patch-series pretty late in the -rc
    series (say, you decide to apply things at -rc6 or so), I suspect you'll
    never have any real reason to do a "git pull" at all, although it's also
    certainly not wrong to do test branches to check that everything is ok,
    for example.

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

    Yes. That's a good model.


     \ /
      Last update: 2008-05-18 02:39    [W:0.045 / U:6.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site