On Mon, 06 Nov 2017 at 10:25:03 -0600, Tyler Hicks wrote:
> On 11/05/2017 05:55 AM, intrigeri wrote:
> > - always pass --upstream-vcs-tag to `gbp import-orig', so that the
> > upstream Git history is merged when importing the new release
> > tarball
>
> When you say that the upstream git history is merged, do you mean that
> it is squashed into a single commit with a message like "Import v2.12
> from upstream"?
No, that would be the workflow without --upstream-vcs-tag.
The baseline gbp workflow without --upstream-vcs-tag (which intrigeri is
*not* proposing) is that the "upstream" or "upstream/latest" branch in
the packaging repository contains imports of the tarballs that upstream
releases (or sometimes, edited versions of those tarballs from which
non-free files have been removed), which means it's completely decoupled
from upstream's "real" git history. Real-world example:
git clone https://anonscm.debian.org/git/pkg-games/quakespasm.git
If you use gbp import-orig --upstream-vcs-tag as intrigeri is proposing,
then the upstream/latest branch in the packaging repository still
contains imports of tarballs (because the dpkg source package format is
fundamentally tarball-based, and official tarball releases frequently
differ from what's in the upstream git repository by containing
auto-generated files or by not containing non-essential files). The
difference is that now it's a git merge commit, which has the "real" git
history leading up to that release as an ancestor. Real-world example:
git clone https://anonscm.debian.org/git/collab-maint/ostree.git
I'm simplifying a little by saying "upstream/latest" - for packages
where more than one branch is maintained, there can be multiple branches
that track upstream code. https://anonscm.debian.org/git/pkg-utopia/dbus.git
is a real-world example of this, with upstream/latest, upstream/1.10.x
and upstream/1.8.x branches currently of interest.
> > - use `gbp pq' to manage the quilt patch series (but this is left to
> > personal preferences as the patch-queue branch is never pushed, and
> > debian/patches/ remains the common format used for sharing/storing
> > the patch series in Git)
>
> I need to read some more about `gbp pq`. This is the first time I've
> heard of it.
It interoperates with using quilt(1) or just dropping non-conflicting
patches into debian/patches/. If you're happy with those approaches, the
only thing you need to do to be nice to `gbp pq` users is to write the
DEP-3 patch metadata in the form that looks a bit like `git format-patch`
output. (The example in DEP-3 headed "A patch cherry-picked from upstream"
is in this form, and so are all the patches in quakespasm, dbus, ostree,
flatpak, etc.)
However, gbp pq also lets you manage those patches using `git rebase`
*if you want to*, without removing the ability to manage them with quilt
or by hand.
smcv
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
