git-buildpackage / dgit integration

[Ian Jackson]

We spoke today at lunchtime, and I promised to write up our
conclusions.


Background:

(This is all in the context of format `3.0 (quilt)'.)

git-buildpackage normally works with packages-unapplied branches as
the primary interchange format.  dgit needs a patches-applied branch.

The git history made with a dgit-based NMU will, in general, contain
(a) a series of linear commits touching both upstream files and
debian/changelog (but not touching debian/patches) (b) a commit made
by dgit which makes corresonding patch(es) in debian/patches.


1. Pushing with dgit

 * Essentially, dgit replaces debsign and dput.  It does all of: Tag
   signing, dsc signing, changelog signing, git pushing to the dgit
   repos, and the dput.

The plan is that dgit will

 * Detect or be told that we're using a patches-unapplied-based tree
   This might be done automatically, or by explicit instruction via a
   command-line option, or perhaps there would be some user
   configuration to tell dgit whether to guess.  If dgit is to guess,
   it will observe that the tree doesn't match the proposed .dsc if
   treated as patches-applied, and then try treating it as
   patches-unapplied.

 * If using patches-unapplied, dgit push will make, privately,
   a commit which converts the tree to patches-unapplied.  It is that
   commit which will be the dgit push candidate.

 * The private commit might need to have as a parent the previous
   commit on the dgit branch (which wouldn't necessarily be visible
   anywhere else).  dgit would automatically do this if it found a
   changelog entry in the to-push commit, which mentions the same
   version number as the changelog entry found in the previous dgit
   branch state.

 * If using patches-unapplied, keep the tag spaces separate between
   the dgit git repos and the local tree.  That is, patches-applied
   tags wouldn't be fetched into the local tree's refs, nor would the
   dgit-generated signed push authorisation tag be recorded in under
   its actual name. 

   Also, dgit would make a gbp-style unapplied tag, using gbp to
   discover the tag text that gbp would use.  That tag would be made
   locally but not pushed to the dgit-repos.

   The result of all this is two separate tagging worlds, which
   contain tags of the same name referring to different contents.
   Both these tags would be signed by dgit push.

   The dgit infrastructure server would never mistake a non-dgit tag
   for a dgit one, because the dgit tags mention (and are required to
   mention) dgit.  There would be no protection against other programs
   or humans mistaking one kind of tag for the other.

   This is all obviously not ideal.  But it is difficult to see how to
   resolve this problem without changing either gbp, or dgit (and also
   presumably git-dpm), to use a different tag naming convention,
   which I think each of us probably would prefer not to do.  We
   agreed to think about this some more and see if a better idea
   presented itself.

 * When a gbp user wants to incorporate an NMU, the dgit NMU history
   is probably not that helpful because it contains
   mixed-upstream-and-debian commits.

   However, the gbp user can use git-import-dsc on the NMU .dsc.  That
   will contain the correct patches as the gbp user will expect, so
   this is the best workflow.

   Currently the gbp user needs to somehow arrange that they run
   git-import-dsc on the right branch.  (Perhaps this is right be
   default.)  It would be nice if there were some tooling, probably
   part of gbp, which would double check this.

 * .gitignore: We agree that the source package should contain
   .gitignore if the git tree does.  (dgit requires this.)

   If the way that gbp does builds currently ends up with .gitignore
   missing from source packages, this needs to be fixed.

   (We didn't discuss this in detail, but: dgit has a build wrapper
   for gbp but it may be that this is unnecessary and users should
   just use gbp to build.  If this is so, then at the very least the
   dgit documentation should deprecate the dgit gbp-build function.)

 * It would be good if there were documentation explaining how to use
   dgit and gbp together.  We thought this should probably live in the
   gbp package.

   I have a bug report (#794244) against git-dpm which requests such
   documentation for git-dpm, which I offered to rework into a similar
   bug report for gbp.  (I still intend do that, depending on the
   what you think of this summary, etc.)

I think I have covered everything that we spoke about and which is in
my notes.

Thanks,
Ian.