files which are not in git, a subsequent dgit push will fail.
.TP
.BR --clean=dpkg-source | -wd
-Use dpkg-buildpackage to do the build, so that the source package
+Use dpkg-buildpackage to do the clean, so that the source package
is cleaned by dpkg-source running the package's clean target.
This is the default. It requires the package's build dependencies.
.TP
dgit push looks for single .changes file in the parent directory whose
filename suggests it is for the right package and version - or,
if there is a _multi.changes file, dgit uses that.
+
+If the specified
+.I changesfile
+pathname contains slashes, the directory part is also used as
+the value for
+.BR --build-products-dir ;
+otherwise, the changes file is expected in that directory (by
+default, in
+.BR .. ).
+.TP
+.BI --build-products-dir= directory
+Specifies where to find the built files to be uploaded.
+By default, dgit looks in the parent directory
+.BR .. ).
.TP
.BI --existing-package= package
-dgit push needs to canonicalise the suite name. But currently
-there is no way to ask the archive to do this without knowing the
+dgit push needs to canonicalise the suite name. Sometimes, dgit
+lacks a way to ask the archive to do this without knowing the
name of an existing package. Without --new we can just use the
package we are trying to push. But with --new that will not work, so
we guess
.B dpkg
-or use the value of this option.
+or use the value of this option. This option is not needed with the
+default mechanisms for accessing the archive.
.TP
.BR -h | --help
Print a usage summary.
alioth, so that they can be moved later if and when this turns out to
be a good idea.
-Debian Policy needs to be updated to describe the new Dgit .dsc
-field (and to specify that it is an RC bug for that field to refer
-to an unavailable commit).
-
-The method of canonicalising suite names is bizarre. See the
-.B --existing-package
-option for one of the implications.
-
dgit push should perhaps do `git push origin', or something similar,
by default.