[lkml]   [2008]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT pull] x86 fixes for 2.6.26
    2008/5/18 Linus Torvalds <>:

    Hi Linus,

    Thank you for responding. A few more small questions below.

    > 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).
    Yeah, I figured that trying to get a good git workflow up and running
    would probably be the best in the long run.

    > 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
    > it).
    Right. By definition it is just a bunch of random patches queued up in
    that tree so they don't get lost and so that lots of individual people
    don't have to keep re-sending them.

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

    Ok, so let's say I start off my upcomming trivial branch at -rc1 and
    start applying patches to it, then doing a merge with my master branch
    that tracks your tree at points like, say, -rc5, -rc9 etc would be
    fine, but really only needed if there are conflicts (which I can test
    for in a temporary experimental branch) - got it.

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

    Ok, thanks a lot. Now, I have one final question for you.
    In order to be able to play around with the patches, see if they
    apply, fix them up, test for merge conflicts etc etc, I obviously need
    a tree with content, not just a bare tree. But I see on that all the published trees are bare trees.

    So, I assume I create a tree in my homedir like so;
    $ git clone -l -s /pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    create all the branches and do all the work in that one,

    I would have assumed that to then publish my work and create a
    publicly accessile version I'd do;
    $ git clone --bare -l -s /home/juhl/trivial-work-tree

    But that only seems to make my master branch accessible, not new
    branches I create in my work tree. How do I go about doing this

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

     \ /
      Last update: 2008-05-19 00:13    [W:0.035 / U:42.548 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site