[pkg-fso-maint] git-import-orig vs. upstream’s real branch

[Guido Günther]

On Fri, Oct 24, 2008 at 12:29:22AM +0200, Joachim Breitner wrote:
> I’m trying to find a good way to manage packages in git where upstream
> uses git as well, and I share that repository for my Debian packaging. I
> see that the git-buildpackage tools are very suitable for maintaining
> packages where you only import the released source tarballs from
> upstream (into the “upstream” branch), but do not track the upstream’s
> git branch (say, “upstream-master”) itself.
This is basically what I'm doing with multipath-tools.
 http://git.debian.org/?p=pkg-lvm/multipath-tools.git
"master" has the Debian packaging while "upstream/master" is upstream's
master branch. To help git-buildpackage you can then use:

upstream-branch = upstream/master
upstream-tag = %(version)s

in git/gbp.conf.

> I found http://www.eyrie.org/~eagle/notes/debian/git.html
> section “Debian and Upstream Combined” with some suggestions. Basically,
> Russ suggests to have upstream-master in the git repository, but do not
> actually use it for Debian stuff. Instead, import the tarballs to
> upstream as usual and base the Debian branch on that. Note that the
> tarballs usually differ from upstream’s master branch (think automake
> files).

> Is that an sensible approach, in your opinion?
It sure is, I'm doing things a bit differently though. 

a) Worried about the upstream tarball: Simply let pristine-tar handle
that for you. If you use the layout as suggested above on each new
upstream version simply import the tarball with pristine-tar once:

pristine-tar commit <upstream-tarball> upstream/master

If you then build with "git-buildpackage --pristine-tar"
git-buildpackage will build a pristine upstream tarball via pristine-tar
with an identical md5sum.

b) don't care about the upstream tarball at all: Build the upstream
tarball yourself from upstream's tag. There's not really a point in
using the "release" tarball. Upstream's tag is at least just as
meaningful (if not more). In case you team maintain the package you
can again import that generated tarball using pristine-tar once and push
that out so you don't run into md5sum problems.

The drawback of a) here is that you're applying your patches that were
well tested against something completely unknown (the new upstream
tarball) so I do like b) a lot more (ustream is using the same VCS as
you are - great, so let's have all of these advantages). And should
upstream switch VCS again - no worries, you can always fall back to the
orig.tar.gz method by importing these again.

> What I’m missing here is the connection between upstream-master and
> upstream. I’m no git expert, but would it make sense to run
> # git checkout upstream
> # git merge -s ours release/the-version
> where release/the-version is the tag on the upstream-master branch,
> indicating where the tarball was created from? This would tell git that
> the just imported tarball contains all patches from upstream-master, up
> to this point. Is that sensible? If so, would it be useful to add
> support for this to git-import-orig (e.g. a --based-upon flag)?
Not sure. Since b) works out so well I'm not sure it's worth it. But as
usual: if someone comes up with a clean workflow and patches to
implement it I'm more than happy to apply them.

> Also, do you have any suggestions on how to best handle changes in the
> Debian branch that should end up as quilt patches? Currently, we just
> let git maintain the quilt files, but I wonder if there isn’t anything
> smarter? Maybe something like branches per change, which would be turned
> into quilt files by git-buildpackage?
People tend to use TopGit for this and it looks good. I'm not using it
at the moment. I'm using a patch-queue branch that I rebase on my
Debian packaging branch. Like this (assuming you have your Debian
development on master):

git branch patch-queue master
# hack, hack, fix bug A, apply as a clean commit
commit -m "fixed #A"
# fix bug B
commit -m "fixed #B"
# fix bug C by cherry-picking from upstream:
git cherry-pick --edit f3f323eab
git commit -m "fixed #C"

git checkout master
rm -f debian/patches/*
git format-patch -N -o debian/patches master...patch-queue | \
	sed -e 's%debian/patches/%%' > debian/patches/series

The last two lines are actually a target in debian/rules.  Once done I
never switch to patch-queue directly but always do: "git rebase
patch-queue master" to get there.

I don't push out the patch-queue branch since it's being rebased all the
time. Since you have everything in the quilt series you can also drop
the patch-queue branch at any point an recreate it via git-quiltimport -
needed for team maintenance.

Note that this method probably isn't ideal for long term development
where you merge _several_ topic branches that you want to share with
ohters. I'd recommend looking into TopGit then. As long as you're fine
with one "patch-queue" branch it works fairly well (without putting the
burden of learning an additional tool onto the whole team).
Does this help? Comments are welcome, of course,
 -- Guido