Question about Git tree methodology.

Question about Git tree methodology.

[Matt LaPlante]

Hi all,
  I've been playing around with setting up a personal git tree for kernel patches.  I've followed Jeff Garzik's guide, as well as some of the kernel.org docs.  I have no problem setting it up, however I have a question about which method to use for my tree.  Basically I just want to use it as a method of tracking my own trivial patches (and perhaps give maintainers easier access to them).  I've looked through some of the trees on kernel.org for guidance.  
  My issue is, if I do a git clone, I wind up with all the history from the kernel git.  This seems excessive and useless for just tracking my own work.  I could alternatively download the source and init a new tree, but I believe it would make keeping up to date with the kernel.org git more complicated.  
  What method is used by the various trees on kernel.org to deal with this?  Is there a way to use the kernel.org git as a base, but only track my own changes?  

Thanks.

-- 
Matt LaPlante
CCNP, CCDP, A+, Linux+, CQS
kernel1@cyberdogtech.com

Re: Question about Git tree methodology.

[Daniel Drake]

Matt LaPlante wrote:
> Hi all, I've been playing around with setting up a personal git tree
> for kernel patches.  I've followed Jeff Garzik's guide, as well as
> some of the kernel.org docs.  I have no problem setting it up,
> however I have a question about which method to use for my tree.
> Basically I just want to use it as a method of tracking my own
> trivial patches (and perhaps give maintainers easier access to them).

Quilt is very good at doing this kind of thing.
http://savannah.nongnu.org/projects/quilt

It keeps all your patches in a "patches" subdirectory and makes going 
back and fixing previous patches very easy (git makes this quite hard). 
You can rsync your patches/ directory to any webserver, and anyone else 
can save them in a patches subdirectory and apply them in the same way 
(the equivalent of sharing your tree).

Daniel

Re: Question about Git tree methodology.

[Stefan Richter]

Daniel Drake wrote:
> Matt LaPlante wrote:
[...]
>> Basically I just want to use it as a method of tracking my own
>> trivial patches (and perhaps give maintainers easier access to them).
> 
> Quilt is very good at doing this kind of thing.
> http://savannah.nongnu.org/projects/quilt

Introductory documentation:
http://cvs.savannah.nongnu.org/viewcvs/*checkout*/quilt/doc/quilt.pdf?root=quilt

> It keeps all your patches in a "patches" subdirectory and makes going 
> back and fixing previous patches very easy (git makes this quite hard). 
> You can rsync your patches/ directory to any webserver, and anyone else 
> can save them in a patches subdirectory and apply them in the same way 
> (the equivalent of sharing your tree).

Hi Matt,

yes, Quilt is a good tool especially for maintenance of patch
collections on top of evolving source trees. I for one use it to keep
track of patches for the subsystem of my interest (ieee1394 drivers), to
develop new patches asynchronously to mainline releases, and to publish
'backports': http://me.in-berlin.de/~s5r6/linux1394/updates/

The "patches" subdirectories at this site is what quilt itself is
working on. Examples of basic tasks are
$ quilt import   # add a foreign patchfile to quilt's collection
$ quilt push     # apply next patch listed in patches/series
$ quilt pop      # unapply current patch
$ quilt refresh  # regenerate the diff of the current patch after the
                   sources have been edited or otherwise changed

To submit patches to maintainers, either post them with your usual mail
user agent or let "quilt mail ..." prepare the postings or --- as Daniel
wrote --- publish them on a server. In the latter case, take care to
prepend mbox-like headers (especially a "From: " header to denote the
patch's author) so that git users can import those patchfiles easily
with "git am". (The patches on my site still lack those headers because
I rarely forward patches from other authors.)

There are things that Quilt does _not_ do for you:
 - update the underlying source tree from other repos
 - generate changelogs (I wrote a simple script around Quilt to generate
   the changelogs at my site. But that script is quite slow if it has to
   handle a bigger number of patches.)
 - certainly a few other things which Quilt wasn't intended for...

If you plan to intensively interact with git trees, StGIT ("Stacked GIT"
 alias "stg") may also be worth a look: http://www.procode.org/stgit/
I haven't tried StGIT myself yet. AFAICS it provides basically the same
functions as Quilt with two apparent differences:
 - The three steps to update the underlying source tree "quilt pop -a;
   git pull ...; quilt push -a" are available as a single command:
   "stg pull ...". Big deal.
 - The steps to commit your patches into the underlying git tree are
   easily performed by "stg commit".
After a patch was committed to the git tree, you loose the ability to
modify the patch as freely as you could while it was managed by quilt or
StGIT.

To summarize, Quilt or StGIT are a good choice if you plan to develop or
maintain patches which you want to change (update, improve...) in a
different rhythm than the underlying source tree. This is what many
"upstream developers" as well as "downstream distributors" do. Upstream
developers may need to update their patches sometimes a few times before
final submission, e.g. based on change requests from reviewers, or
because the order of patches is to be changed to submit newer critical
patches before older but less critical patches. Downstream distributors
maintain add-ons (e.g. out-of-tree feature patches, customizations,
backported bug fixes) on top of a source tree from upstream.
-- 
Stefan Richter
-=====-=-==- -=== ==---
http://arcgraph.de/sr/