(a) The git-buildpackage manual [0] mentions, and [1] further discusses,
a workflow that imports *both* upstream's git and upstream's tarball of
the same release:
upstream-vcs uuuuuUuuuuuuuuuuuuuuuuuuuuuuUuuuuuuuuu
\ \
upstream-for-gbp ------i----------------------i-------
\ \
debian ---------ippppP------ppP--------ippP--
u, U = upstream commit, release
p, P = packaging commit, release
i = tarball+git import (gbp import-orig --upstream-vcs-tag)
gbp --upstream-branch points to upstream-for-gbp
upstream-vcs's remote points to upstream's repo
This also allows git-only and tarball-only imports to coexist with the
above and each other:
upstream-vcs uuuuuUuuuuuuuuuuuUuuuuuuuuuuUuuuuuuuuu
\ \
upstream-for-gbp ------m-----------\----------o-------
\ \ \
debian ---------mppppP------mppP-------oppP--
m = git only import (git merge or gbp import-ref)
o = tarball only import (gbp import-orig)
(Building the second form of git-only requires temporarily pointing
--upstream-branch to upstream-for-gbp, so I suggest preferring the first
one for the occasional unreleased-so-no-tarball snapshot in a normally
tarball-using repository.)
This option seems to be missing from the wiki page [2]: it only has
git-only, tarball-only, and "salsa git from upstream git only, archive
.orig from tarball" (noting the "they might not match" problem with the
last). Is this omission a recommendation against it, or should it be added?
-------------------
(b) How do I deal with branch/tag name conflicts between upstream and
packaging?
There are at least two ways conflicts can happen by accident:
(i) gbp defaults to naming the packaging branch 'master', which is
also plain git's default name for the first branch of a new repository.
(ii) gbp's upstream-branch/-tag settings are used both for reading
(build) and writing (import-orig). Hence, if a contributor using
upstream-as-git commits a debian/gbp.conf with these set to the upstream
branch name and tag format, then another contributor imports an upstream
tarball with gbp import-orig, the tarball-import commit ends up on what
was the upstream-as-git branch with an upstream-format tag name [3].
Given that Git considers the same final contents via a different history
to be a different commit number, I suspect (but haven't tried) that this
makes that branch no longer usable for 'git pull' from upstream.
[4] suggests that the command to pull a branch with a different name is
git branch -u upstream/master upstream-vcs
Is this correct, and will it sanely handle tag conflicts (e.g. by
skipping the conflicting tags)?
Is there a convention for what name to give this branch?
Is there a standard way to tell gbp "this is an upstream-as-git-only
repository, don't import tarballs" to prevent (ii) in future? (Avoiding
(i) for new repositories is DEP-14 / #829444.)
[0]
https://sources.debian.org/src/git-buildpackage/0.9.14/docs/chapters/import.xml/#L233,
or if you have it installed,
file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664771
[2] https://wiki.debian.org/GitPackagingSurvey
[3] I have seen what appears to be a real example of this on Salsa.
[4]
https://github.com/Debian/pkg-go-tools/blob/master/cmd/pgt-remote-add-upstream/upstream.go
