RFR: GIT Package VCS

Karel Zak kzak at redhat.com
Thu Jun 7 23:39:40 UTC 2007

On Thu, Jun 07, 2007 at 10:25:11AM -0400, Jeremy Katz wrote:
> On Wed, 2007-06-06 at 22:46 -0400, Christopher Blizzard wrote:
> > On Wed, 2007-06-06 at 17:31 -0400, Jeremy Katz wrote:
> > > At the same time, I think we still need to be able to very clearly
> > > separate out our changes from what upstream has.

> And fundamentally, I think that the "pristine source + patches" bit is
> just as important today as it was 10 years ago.  Because otherwise, you
> get into a situation where you basically encourage forking and not
> contributing things back upstream.  Your response is going to be "but

 I think that maintain "tarballs + patches" is no good idea.  This
 thing is *very good* for distribution in src.rpms, but I hate it in
 VCS. I'd like to see all code (include upstream code) in VCS.

 You can still export all your changes from GIT as small patches. The
 solution is branches. You can use one branch for pristine upstream
 source code and other branch for upstream code + fedora patches.

 Finally, you can export pristine source and patches, compress the
 upstream code back to tarball and distribute the tarball + patches
 by src.rpm.

 My wish is "git rebase" always after upgrade to new upstream code.
 The current "make prep" is nightmare...

 See Linux kernel. That's normal that people maintain their patches
 outside official tree(s) for pretty long time. The modern VCS is the
 right tool for this job.

 "separate out our changes from what upstream has" .. is definitely
 no problem.


 Karel Zak  <kzak at redhat.com>

More information about the Fedora-infrastructure-list mailing list