On 29/07/15 13:48, Ian Jackson wrote:
> I got the impression that gbp normally works with a patches-unapplied
> tree. Is that correct ? If so then an additional gbp step may be
> needed, to convert the tree to patches-applied.
"gbp buildpackage" can work either way, but I think most gbp users
consider a patches-unapplied tree to be what they normally work with
(for instance that's what the pkg-perl team uses).
If you use "gbp pq" (which I would recommend over quilt for anyone who
likes the patches-unapplied model and git), then you get local,
transient branches like patch-queue/master, which are imported from
debian/patches and not normally pushed. Each of those consists of the
relevant patches-unapplied commit, plus the patches applied in sequence
as git commits:
(older history)
|
master \ fix foo
| \ change bar
| patch-queue/master
|
experimental \ fix foo
\ change bar
patch-queue/experimental
http://honk.sigxcpu.org/piki/development/debian_packages_in_git/ has
more about this.
To make this work with dgit, I think it would be necessary to build from
(and tag) patch-queue/master instead of master, after doing a "git merge
-s ours" from the previous tip of patch-queue/master (most conveniently
represented by a previous tag) so that history is fast-forwarding. You'd
essentially end up with each tag being a descendant of master, but not
actually a former state of master.
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b937e7.60...@debian.org
