Brian May writes ("Re: a poll for Dgit workflows"):
> I think the single-debian-patch makes doing security updates a lot
> harder. Particularly if one distribution has been patched, and the patch
> needs to be ported to other distributions.
>
> Sure, you might be able to retrieve/store the individual patches from
> git, however we don't have any one standard for storing the patches in
> git. This means in order to do security updates, the first step would be
> to learn how this particular packages stores the patches in git. Unlike
> 3.0-quilt format which is a standard that most packages use (or some
> similar storing of patches in debian/patches at least).
There is essentially only one reasonable way to export a patch stack
in git, which is as a git branch with one commit per patch. There
will usually be a synthetic merge commit at the top, to make the
result a fast forward from the previous version. Most of the popular
git workflow tools we already have work with some form of this
representation.
(NB that dgit is not a git workflow tool; it's a publication tool.)
If one does this, right now, there are rather too many manual git
runes and rather too much understanding, required, for simply
exchanging such git branches to be sensible recommendation as a
default workflow.
But it does work. And if you want to do a new upstream version, you
can do it by rebasing the branch onto the new upstream version in
git. (Your new upstream version is in git already, right?)
I have plans for ways to improve the workflow to be more automatic
more cooked, but for now I'm concentrating on getting the git-dpm and
gbp integration to work right.
> I haven't looked at dgit in sometime, so I can't recall how well it
> works - assuming it does work - with 3.0-quilt format.
It works just fine with `3.0 (quilt)'. The import/export could be
improved but it meets its basic design goals.
There are difficulties with the data models of some of the existing
git workflow tools. In particular, dgit is hard to use with
git-buildpackage. I'm working on that.
Ian.
