Messages in this thread | | | Date | Wed, 28 Nov 2007 20:10:52 +0100 | From | willem <> | Subject | Re: 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/
| |