than ideal.
I intend to improve this, perhaps by having dgit use git-dpm as a
-bidirectional gateway between `3.0 (quilt)' and git.
-
-This will generate a rebasing-style git branch. After a patch series
-has been edited with rebase, dgit push will have to generate a `fake
-merge' commit to make the resulting history fast-forwarding. (This is
-a well-understood git manipulation.)
+bidirectional gateway between `3.0 (quilt)' and git. Exactly how to
+do this involves some complicated design decisions which I haven't
+entirely worked out yet. The intent, though, is that there will be an
+option to generate a rebasing-style git branch. After a patch series
+has been edited with rebase, dgit push will generate a `fake merge'
+commit to make the resulting history fast-forwarding.
(ACCESS PROBLEMS)
useable for DDs. This is particularly galling for a tool which is
especially useful for users, downstreams, mentees, and so forth.
-There are two obstacles to widening the access, relating to the
-archive and to the git server.
+There are two obstacles to widening the access, one relating to the
+archive and one to the git server.
Firstly, dgit needs to query the archive to find the current version
of the package and obtain a copy of the .dsc. At the moment there is