lkml.org 
[lkml]   [2007]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: git guidance
    Dave Quigley wrote:
    > On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote:
    >
    >> Dave Quigley schrieb:
    >>
    >>> There is a project listed on the kernel.org git page called guilt. I
    >>> find it very useful. It is much more responsive than stgit and it
    >>> actually has a git backend which quilt does not.
    >>>
    >>> On Wed, 2007-11-28 at 00:20 +0100, Jan Engelhardt wrote:
    >>>
    >>>> On Nov 27 2007 23:33, Tilman Schmidt wrote:
    >>>>
    >>>>> Well, it did. So now I'm back to keeping a virgin kernel source tree
    >>>>> alongside my development area in order to produce diffs. That can't
    >>>>> be right?
    >>>>>
    >>>>>
    >>>> No, it can't. Use stgit/quilt ;p
    >>>>
    >> In which respect would stgit/quilt/guilt help me? At first glance
    >> they just seem to add another level of complexity.
    >>
    >> Thanks,
    >> Tilman
    >>
    >>
    >
    > These tools allow you to maintain a set of patches with very little
    > effort. More importantly it removes a lot of the git specifics from your
    > development process. For example this is how I use guilt for a new patch
    > set.
    >
    > I take my fresh tree and do a guilt-init in the base. This will create a
    > new patch series. I then need to create a patch to modify something LSM
    > related (guilt-new <patch_name>). Things like stgit/quilt/git use the
    > idea of a stack of patches. At this point if you were to type
    > guilt-series you would only see the one patch we just created. This
    > patch is going to be one logical set of changes (it should also produce
    > a compilable and working kernel). You can make whatever modifications
    > you need to make to your files and at this point you need to do one of
    > two things. If they were already in the tree you just type guilt-refresh
    > and under your .git/patches/<branch_name> directory you will see a file
    > named <patch_name> which contains your patch. Otherwise you need to do a
    > guilt-add <file_name> and then a guilt-refresh. The idea here is that
    > you have a moved your workflow from managing a series of commits and
    > then breaking out patches from a final version to one where you think in
    > terms of the patches and make modifications to them instead. In my
    > example I said I was doing something LSM related. Lets say the first
    > patch added a new hook and its implementation in the various modules. We
    > can now add a second patch using the guilt-new command and this one will
    > add uses of that new hook. At this point we have a stack that looks like
    > this.
    >
    > <patch that adds users>
    > <patch that adds hook>
    >
    > I can pop and push patches onto this stack to have a version of my
    > kernel tree at any state within the patch set. At this point lets say we
    > have posted the patch set and have feedback. I need to apply this
    > feedback to the patch that adds the LSM hook. Since my top patch
    > (guilt-top) is currently at the one that adds the users of the hook I
    > need to pop off that patch and get to the one that creates the hook
    > (guilt-pop). After doing this I'm at a kernel tree state which just has
    > the changes which add the hook. I make my modifications, type
    > guilt-refresh to create a new patch and then guilt-push my second patch
    > on and make sure everything is still working.
    >
    > As you can see there is almost no git knowledge required to use this
    > system and it allows you to focus on development instead of the
    > versioning system. One useful feature is that when Linus adds new
    > patches and I want to rebase my set against the current tree It only
    > takes 3 commands to rebase the patch set (Assuming all goes well).
    >
    > guilt-push -a #push all patches onto the stack
    > git-fetch #pull down the index
    > guilt-rebase FETCH_HEAD #Rebase our patches should do a merge and
    > #reapply all patches
    >
    > These are just some basics about guilt. Jeff has written a better
    > tutorial with a sample repository for you to work with if your
    > interested. I don't know if this will help your development process but
    > I can tell you from experience breaking patches by hand was a pain in
    > the ass and a huge waste of time and I'm glad to have a tool like this
    >
    Where can I find that tutorial ?

    regards
    > now.
    >
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    >
    >

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-11-28 20:39    [W:3.253 / U:1.924 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site