Tagging and signing should be left to dgit push.
.B dgit push
-does an "upload", pushing the current HEAD to the archive (as a source
+does an `upload', pushing the current HEAD to the archive (as a source
package) and to dgit-repos (as git commits). This also involves
making a signed git tag, and signing the files to be uploaded to the
archive.
dgit push looks for single .changes file in the parent directory whose
filename suggests they it is for the right package and version.
.SH BUGS
-dgit currently only works with Format 1.0 packages.
-
dgit is not nearly configurable enough. The locations for dgit-repos
(on alioth) and for the Debian archive are currently hardcoded.
There is not yet any support for suites which are in different
currently any mechanism for determining and honouring the archive's
ideas about access control. Currently only DDs can push.
-dgit's representation of Format 3.0 (quilt) source packages (even if
+dgit's representation of format `3.0 (quilt)' source packages (even if
they were supported) would not represent the patch stack. Currently
the patch series representation cannot round trip through the archive.
Ideally dgit would represent a quilty package with an origin commit of
some kind followed by the patch stack as a series of commits followed
by a pseudo-merge (to make the branch fast-forwarding). This would
-also mean a new "dgit rebase-prep" command or some such to turn such a
-fast-forwarding branch back into a rebasing patch stack, and a "force"
+also mean a new `dgit rebase-prep' command or some such to turn such a
+fast-forwarding branch back into a rebasing patch stack, and a `force'
option to dgit push (perhaps enabled automatically) which will make
the required pseudo-merge.