dgit vs git-series

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Josh Triplett writes ("Re: [ANNOUNCE] git-series: track changes to a patch series over time"):
> On Fri, Aug 12, 2016 at 12:31:49PM +0100, Ian Jackson wrote:
> > Josh Triplett writes ("Re: [ANNOUNCE] git-series: track changes to a patch series over time"):
> > > For repositories, you can push the series branch directly if you want to
> > > provide the history of your series, or you can push the current version
> > > (or an older version) of the patch series if you just want to publish
> > > that version.
> > 
> > Neither of these is compatible with dgit, of course.
> 
> The former seems the easiest to interoperate with: dgit could easily
> learn to receive a series commit and turn it into a source package ready
> for upload.

I think you have fundamentally misunderstood what dgit is.

dgit is primarily a mechanism for 1. publishing git histories which
are guaranteed to be identical[1] to the archive contents
2. gatewaying between the archive and such git histories (synthesizing
the git history out of whole cloth if necessary).

dgit's users rely on the fact that dgit git branch (for each suite in
the archive) is a normal, fast-forwarding, git branch, containing the
source package.  Providing such a view (of any package in the archive)
is dgit's main purpose.

This ensures that dgit users (including people other than the
maintainer) can pull from the dgit git branch, exchange it with each
other like a normal git branch, build binary packages, and work with
the source code.  They can do all this without needing to understand
the specific packaging workflows in use by the maintainer and without
using special tools other than git itself.

When the maintainer did not use dgit push, dgit synthesises a history
out of the archive contents.  This is, of course, not ideal.

Maintainers who are using git can publish their git history with dgit,
so that dgit users can see it, but only if their git history meets
these requirements.  If the maintainer's workflow does not meet these
requirements then either it must be converted somehow, or the
maintainer cannot use `dgit push' (and dgit users will see the rather
unhelpful synthetic history).

Neither of your git branches have both of the properties required of
the dgit branch: instead, they each have only one of the required
properties.  Your :series branch is not fast forwarding, and your
git-series branch does not have the right tree objects to be used
directly.

If your tool becomes popular, I might try to do for it, what I am
doing for git-buildpackage: write functionality in dgit which converts
one or both of your tool's branches into a branch which is both
 1. a normal git branch that can be worked on directly
 2. fast forwarding

But that's way down my priority list right now.

Thanks for your attention.

Ian.

[1] Because of `3.0 (quilt)', the definition of `identical' is not
entirely straightforward.  But there is exactly one tree object
corresponding to any source package (and ideally as few different
commits, corresponding to any source package, as possible).

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.