On Wed, Jul 16, 2008 at 12:04:38AM +0200, Stefano Zacchiroli wrote: > On Tue, Jul 15, 2008 at 01:45:16PM -0700, Russ Allbery wrote: [..snip..] > > FWIW, I've been keeping notes on what I'm personally doing at: > > http://www.eyrie.org/~eagle/notes/debian/git.html Very interesting reading! > > This is very interesting, thanks a lot for it! What others here do think > of the workflow / branch layout you propose? Are there any other usual > suspect as possible workflows / layouts? Despite of filtering non dfsg things out onto upstream/ already I usually import the verbatim upstream sources as is and create a dfsg-clean branch instead:
git-branch dfsg-clean upstream rm doc/rfc* and in $REPO/.git.conf: [git-buildpacakge] upstream-branch = dfsg-clean [git-import-orig] debian-branch = dfsg-clean This lets git-buildpackage build the orig.tar.gz form dfsg-clean while git-import-orig merges onto dfsg-clean instead of master (so if you've removed the rfcs once, they'll stay gone forever). This is has the minimal advantage that co-maintainers don't have to worry about the correct import line when importing new upstream versions. Concerning backports I'm usually using bpo/<release> branches (e.g. bpo/sarge, bpo/etch). This way you can handle backports for different versions easily. I also keep the simple "just add another changelog entry" changes there so that I have a history of what versions were backported. Cheers, -- Guido _______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
