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
