Re: Ad-hoc survey of existing Debian git integration tools
Simon McVittie writes ("Re: Ad-hoc survey of existing Debian git integration tools"):
> "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).
Right.
(dgit needs to see the patches-applied tree, because a key feature of
dgit is that someone who does `dgit clone foo' gets a git tree for foo
that they can work on, and commit on, without having to know anything
about the maintainer's preferred source format or git workflow.)
> 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:
That sounds sensible.
> http://honk.sigxcpu.org/piki/development/debian_packages_in_git/ has
> more about this.
Thanks, l will read.
> 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.
If you get an NMU, or want to work from the dgit history as the main
history rather than keeping the primary branch somewhere else, you
also need to be able to (a) strip off the `git merge -s ours' and
(b) deal with any NMU commits which have appeared on top of the dgit
branch.
Of course you can do that manually with an appropriate `git reset' and
some cherry picking, but that seems like it will be fiddly and error
prone.
Do we need some additional tool features in this area ?
Ian.
Reply to: