RFR: GIT Package VCS

[Mark McLoughlin]

On Mon, 2007-06-11 at 10:23 +0100, Mark McLoughlin wrote:
> > On Thursday 07 June 2007 21:59:27 Toshio Kuratomi wrote:
> > > On Thu, 2007-06-07 at 21:18 -0400, Jesse Keating wrote:
> > > > <strawman>
> > > > We have two things for the upstream in our package SCM.  We have the
> > > > prestine tarball stashed away in a lookaside, and we have an exploaded
> > > > tree of the source.  We use the exploaded tree of the source to manage
> > > > our patches to that source and to help with rebases.  However the patches
> > > > we manage always apply to the prestine point.  At package build time, the
> > > > patches we manage + the spec file + the prestine tarball stashed away are
> > > > combined to make an srpm, and that is shoved through the build system.
> > > > </strawman>
> 
> 	I wonder. What are we trying to do here?
> 
>   1) Make hacking on a stack of patches easier
> 
>   2) Make it easier to re-base - i.e. new upstream tarball, re-generate 
>      each of the patches against the new upstream, resolving any
>      conflicts
> 
>   3) Allow someone to fork a set of patches? e.g. OLPC has their own 
>      version of a package with an additional patch, but wants to keep 
>      in sync with the Fedora version of the package
> 
> 	I'd suggest quilt as a nice simple tool for (1). Stacked git (stg)
> looks like it makes sense if upstream uses git.

	I forgot about patch history, which others have mentioned. Very useful
in some cases.

	Perhaps it'd be worth prototyping this with stg:

  - "make stg-init" to create a new stg/git repo, import the current 
    upstream tarball

  - "make stg-push" to push that repo to some well-defined location for 
    each package

  - "make stg-rebase" to import the current source tarball into stg, 
    re-push all patches and manually resolve any conflicts

  - "make stg-patches" to export all the patches from stg, add them to 
    pkgs cvs and create $package.patches and $package.applies files, 
    both of which can be %included from the spec file

Cheers,
Mark.