+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. 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. This option is not needed with the
+default mechanisms for accessing the archive.
+.TP
+.BR -h | --help
+Print a usage summary.
+.TP
+.BI --initiator-tempdir= directory
+dgit rpush uses a temporary directory on the invoking (signing) host.
+This option causes dgit to use
+.I directory
+instead. Furthermore, the specified directory will be emptied,
+removed and recreated before dgit starts, rather than removed
+after dgit finishes. The directory specified must be an absolute
+pathname.
+.TP
+.BI --no-rm-on-error
+Do not delete the destination directory if clone fails.
+.SH WORKFLOW - SIMPLE
+It is always possible with dgit to clone or fetch a package, make
+changes in git (using git-commit) on the suite branch
+.RB ( "git checkout dgit/" \fIsuite\fR)
+and then dgit push. You can use whatever gitish techniques you like
+to construct the commit to push; the only requirement is that it is a
+descendant of the state of the archive, as provided by dgit in the
+remote tracking branch
+.BR remotes/dgit/dgit/ \fIsuite\fR.
+
+If you are using dgit to do an NMU, and don't know about the
+maintainers' preferred packaging workflows, you should make your
+changes as a linear series of (logicially separated) commits on top of
+what's already in the archive.
+
+If you are lucky the other uploaders have also used dgit and
+integrated the other relevant git history; if not you can fetch it
+into your tree and cherry-pick etc. as you wish.
+.SH WORKFLOW - INTEGRATING BETWEEN DGIT AND OTHER GIT HISTORY
+If you are the maintainer of a package dealing with uploads made
+without dgit, you will probably want to merge the synthetic commits
+(made by dgit to represent the uploads) into your git history.
+Normally you can just merge the dgit branch into your own master, or
+indeed if you do your work on the dgit local suite branch
+.BI dgit/ suite
+you can just use dgit pull.
+
+However the first time dgit is used it will generate a new origin
+commit from the archive which won't be linked into the rest of your
+git history. You will need to merge this.
+
+If last upload was in fact made with git, you should usually proceed
+as follows: identify the commit which was actually used to build the
+package. (Hopefully you have a tag for this.) Check out the dgit
+branch
+.RB ( "git checkout dgit/" \fIsuite\fR)
+and merge that other commit
+.RB ( "git merge debian/" \fIversion\fR).
+Hopefully this merge will be trivial because the two trees should
+be the same. The resulting branch head can be merged into your
+working branches
+.RB ( "git checkout master && git merge dgit/" \fIsuite\fR).
+
+If last upload was not made with git, a different approach is required
+to start using dgit. First, do
+.B dgit fetch
+(or clone) to obtain a git history representation of what's in the
+archive and record it in the
+.BI remotes/dgit/dgit/ suite
+tracking branch. Then somehow, using your other git history
+plus appropriate diffs and cherry picks from the dgit remote tracking
+branch, construct a git commit whose tree corresponds to the tree to use for the
+next upload. If that commit-to-be-uploaded is not a descendant of the
+dig remote tracking branch, check it out and say
+.BR "git merge -s ours remotes/dgit/dgit/" \fIsuite\fR;
+that tells git that we are deliberately throwing away any differences
+between what's in the archive and what you intend to upload.
+Then run
+.BR "dgit push"
+to actually upload the result.
+.SH CONFIGURATION
+dgit looks at the following git config keys to control its behaviour.
+You may set them with git-config (either in system-global or per-tree
+configuration), or provide
+.BI -c key = value
+on the dgit command line.
+.TP
+.BI dgit-suite. suite .distro
+.TP
+.BI dgit.default.distro
+.TP
+.BI dgit-distro. distro .username
+.TP
+.BI dgit-distro. distro .git-url
+.TP
+.BI dgit-distro. distro .git-user
+.TP
+.BI dgit-distro. distro .git-host
+.TP
+.BI dgit-distro. distro .git-proto
+.TP
+.BI dgit-distro. distro .git-path
+.TP
+.BI dgit-distro. distro .git-check
+.TP
+.BI dgit-distro. distro .git-create
+.TP
+.BI dgit-distro. distro .upload-host
+.TP
+.BI dgit-distro. distro .mirror
+.TP
+.BI dgit-distro. distro .archive-query
+.TP
+.BI dgit-distro. distro .archive-query-default-component
+.TP
+.BI dgit-distro. distro .sshpsql-user
+.TP
+.BI dgit-distro. distro .sshpsql-host
+.TP
+.BI dgit-distro. distro .sshpsql-dbname
+.TP
+.BI dgit-distro. distro .ssh
+.TP
+.BI dgit-distro. distro .keyid
+.TP
+.BR dgit.default. *
+for each
+.BR dgit-distro. \fIdistro\fR . *
+.SH ENVIRONMENT VARIABLES
+.TP
+.BR DGIT_SSH ", " GIT_SSH
+specify an alternative default program (and perhaps arguments) to use
+instead of ssh. DGIT_SSH is consulted first and may contain arguments;
+if it contains any whitespace will be passed to the shell. GIT_SSH
+specifies just the program; no arguments can be specified, so dgit
+interprets it the same way as git does.
+See
+also the --ssh= and --ssh: options.
+.TP
+.BR gpg ", " dpkg- "..., " debsign ", " git ", " curl ", " dput ", " LWP::UserAgent
+and other subprograms and modules used by dgit are affected by various
+environment variables. Consult the documentaton for those programs
+for details.