From: Dave Quigley <dpquigl@tycho.nsa.gov>
To: willem <wli222@casema.nl>
Cc: Tilman Schmidt <tilman@imap.cc>,
Jan Engelhardt <jengelh@computergmbh.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: git guidance
Date: Wed, 28 Nov 2007 14:18:26 -0500 [thread overview]
Message-ID: <1196277506.21012.18.camel@moss-terrapins.epoch.ncsc.mil> (raw)
In-Reply-To: <474DBD3C.8040602@casema.nl>
On Wed, 2007-11-28 at 20:10 +0100, willem wrote:
> 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/
> >
> >
Hmm actually the tutorial in the docs is somewhat minimal. However you
can find it in the Documentation/HOWTO file under the guilt tree once
you clone it. Maybe I can write a better one some day not on work time
though :)
next prev parent reply other threads:[~2007-11-28 19:20 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-27 22:33 git guidance Tilman Schmidt
2007-11-27 22:54 ` J. Bruce Fields
2007-11-27 22:55 ` Kristoffer Ericson
2007-11-27 23:52 ` Willy Tarreau
2007-11-28 0:43 ` Kristoffer Ericson
2007-11-28 0:49 ` Randy Dunlap
2007-11-28 12:49 ` Al Boldi
2007-11-28 13:45 ` Rogan Dawes
[not found] ` <Pine.LNX.4.64.0711281545170.27959@racer.site>
2007-11-28 17:14 ` Al Boldi
2007-11-28 18:14 ` Johannes Schindelin
2007-11-28 18:30 ` Al Boldi
2007-11-28 18:41 ` Jakub Narebski
2007-11-29 5:27 ` Al Boldi
2007-11-29 12:57 ` Kyle Moffett
2007-11-28 13:38 ` Tilman Schmidt
2007-11-28 21:20 ` Willy Tarreau
2007-11-28 11:23 ` Tilman Schmidt
2007-11-28 12:31 ` Kristoffer Ericson
2007-11-27 23:20 ` Jan Engelhardt
2007-11-28 15:15 ` Dave Quigley
2007-11-28 15:57 ` Tilman Schmidt
2007-11-28 16:37 ` Dave Quigley
2007-11-28 19:10 ` willem
2007-11-28 19:18 ` Dave Quigley [this message]
2007-11-28 23:22 ` Haavard Skinnemoen
2007-11-29 12:45 ` Tilman Schmidt
2007-11-29 13:03 ` Haavard Skinnemoen
2007-11-28 7:41 ` Arkadiusz Miskiewicz
2007-11-29 12:51 ` Tilman Schmidt
2007-11-29 15:52 Jing Xue
2007-11-29 16:19 ` Linus Torvalds
2007-12-01 6:50 ` Al Boldi
2007-12-04 22:21 ` Phillip Susi
2007-12-07 17:35 ` Al Boldi
2007-12-06 18:24 ` Andreas Ericsson
2007-12-07 18:55 ` Al Boldi
2007-12-06 20:22 ` Johannes Schindelin
2007-12-07 4:37 ` Al Boldi
2007-12-07 8:40 ` Andreas Ericsson
2007-12-07 10:53 ` Al Boldi
2007-12-07 11:47 ` Jakub Narebski
2007-12-07 19:04 ` Al Boldi
2007-12-07 19:36 ` Valdis.Kletnieks
2007-12-07 22:07 ` Luke Lu
2007-12-08 4:56 ` Al Boldi
2007-12-08 5:16 ` Valdis.Kletnieks
2007-12-08 10:41 ` Al Boldi
2007-12-08 11:13 ` Johannes Schindelin
2007-12-07 12:30 ` Andreas Ericsson
2007-12-07 21:17 ` david
2007-12-07 22:00 ` Björn Steinbrink
2007-12-06 21:46 ` Phillip Susi
2007-12-08 6:33 ` Martin Langhoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1196277506.21012.18.camel@moss-terrapins.epoch.ncsc.mil \
--to=dpquigl@tycho.nsa.gov \
--cc=jengelh@computergmbh.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tilman@imap.cc \
--cc=wli222@casema.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).