RFR: GIT Package VCS
Mark McLoughlin
markmc at redhat.com
Mon Jun 11 09:43:39 UTC 2007
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.
More information about the devel
mailing list