On Tue, Sep 6, 2011 at 7:27 PM, Jef Spaleta <jspaleta(a)gmail.com> wrote:
As more projects become git based over time, the preferred form for
development might actually be a bisectable git checkout
+100 -- some of the git primitives seem to be here to stay - a hash
identifying a commit or tree as the key identity, plus repo url, and
optionally a branchname. You can see those 3 with minimal variation
Perhaps fedpkg could grow some tentacles to make it easy to replace
the source tarball with a reference to a commit hash, and perhaps to
point to a 2nd repo/branchname/hash where the "as patched in this
fedora rpm" branch is available. That commit being a direct descendant
of the "upstream commit".
If you define the config stanzas and internal API around those 2
triplets, I think you can start with git and then extend to the
relevant DSCMs .
This would make rebasing patchsets (dropping patches as upstream
merges or nixes them) -much- easier.
It would require a 2nd set of git repos, however, where fedora has
full clones of upstream's git repo with the fedora-specific branches.
Upstream projects may or may not welcome the fedora braches in their
repo... Fedora may want to keep more direct control over them re
commit access and direct manipulation (branch renames, etc).
Maybe that can be rolled into what's tracked in pkgs.fp.org
, but the
size difference is... um... :-)
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first