RFR: GIT Package VCS

[Toshio Kuratomi]

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>
> 
So I see two ways to store patches:
 vendor-branch
  |
  |-- Foo.patch branch
  |
  |-- Bar.patch branch

Foo.patch and Bar.patch both directly apply to the upstream vendor
branch.

 vendor-branch
  |
  |-- Foo.patch branch
       |
       |-- Bar.patch branch

Foo.patch is the first patch against vendor-branch.  Bar.patch is
committed to the combination of vendor-branch and Foo.patch.

At first I was hoping to do the first way as it makes it easier to
cherrypick changes for upstream.  However, it quickly became complex as
we had to manage a separate merge branch that was equivalent to the
second storage graph.  Whenever we rebased we would potentially have to
remove conflicts from the second graph as well as the first.

So I decided that going directly to the second style was preferable.
That does not have the enhanced cherrypicking benefits to upstream but
it still allows us to work with individual patches within the VCS more
easily than when they were simply patches stored in CVS.

Do you see a way around this limitation?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20070607/00656081/attachment.sig>