-dgit expects repos that it works with to have a
-.B dgit
-remote. This refers to the well-known dgit-repos location
-(currently, the dgit-repos project on Alioth). dgit fetch updates
-the remote tracking branch for dgit/suite.
-
-dgit does not (currently) represent the orig tarball(s) in git; nor
-does it represent the patch statck of a `3.0 (quilt)' package. The
-orig tarballs are downloaded and kept in the parent directory, as with
-a traditional (non-gitish) dpkg-source workflow.
-
-To a user looking at the archive, changes pushed using dgit look like
-changes made in an NMU: in a `3.0 (quilt)' package the delta from the
-previous upload is recorded in a new patch constructed by dpkg-source.
-.SH PACKAGE SOURCE FORMATS
-If you are not the maintainer, you do not need to worry about the
-source format of the package. You can just make changes as you like
-in git. If the package is a `3.0 (quilt)' package, the patch stack
-will usually not be represented in the git history.
-
-If you are the maintainer of a non-native package, you currently have
-two sensible options:
-
-Firstly, you can regard your git history as primary, and the archive
-as an export format. For example, you could maintain topic branches
-in git and a fast-forwarding release branch; or you could do your work
-directly in a merging way on the
-.BI dgit/ suite
-branches. If you do this you should probably use a `1.0' format
-source package if you can. In the archive, the delta between upstream
-will be represented in the single Debian patch.
-
-Secondly, you can use `3.0 (quilt)', and regard your quiltish patch
-stack in the archive as primary. You will have to use other tools
-besides dgit to import and export this patch stack. But see below:
-.SH FORMAT 3.0 (QUILT)
-For a format `3.0 (quilt)' source package, dgit may have to make a
-commit on your current branch to contain metadata used by quilt and
-dpkg-source.
-
-This is because (i) the `3.0 (quilt)' source format cannot represent
-certain trees, and (ii) packing up a tree in `3.0 (quilt)' and then
-unpacking it does not always yield the same tree. Instead,
-dpkg-source insists on the trees having extra quilty metadata and
-patch files in the debian/ and .pc/ directories, which dpkg-source
-sometimes modifies.
-
-dgit will automatically work around this braindamage for you when
-building and pushing. The only thing you need to know is that dgit
-build, sbuild, etc., may make a new commit on your HEAD. If you're
-not a quilt user this commit won't contain any changes to files you
-care about.
-
-You can explicitly request that dgit do just this fixup, by running
-dgit quilt-fixup.
-
-We recommend against the use of `3.0 (quilt)'.
-.SH FILES IN THE SOURCE PACKAGE BUT NOT IN GIT
-This section is mainly of interest to maintainers who want to use dgit
-with their existing git history for the Debian package.
-
-Some developers like to have an extra-clean git tree which lacks files
-which are normally found in source tarballs and therefore in Debian
-source packages. For example, it is conventional to ship ./configure
-in the source tarball, but some people prefer not to have it present
-in the git view of their project.
-
-dgit requires that the source package unpacks to exactly the same
-files as are in the git commit on which dgit push operates. So if you
-just try to dgit push directly from one of these extra-clean git
-branches, it will fail.
-
-As the maintainer you therefore have the following options:
-.TP
-\(bu
-Persuade upstream that the source code in their git history and the
-source they ship as tarballs should be identical. Of course simply
-removing the files from the tarball may make the tarball hard for
-people to use.
-.IP
-One answer is to commit the (maybe autogenerated)
-files, perhaps with some simple automation to deal with conflicts and
-spurious changes. This has the advantage that someone who clones
-the git repository finds the program just as easy to build as someone
-who uses the tarball.
-.TP
-\(bu
-Have separate git branches which do contain the extra files, and after
-regenerating the extra files (whenever you would have to anyway),
-commit the result onto those branches.
-.TP
-\(bu
-Provide source packages which lack the files you don't want
-in git, and arrange for your package build to create them as needed.
-This may mean not using upstream source tarballs and makes the Debian
-source package less useful for people without Debian build
-infrastructure.
-.LP
-Of course it may also be that the differences are due to build system
-bugs, which cause unintended files to end up in the source package.
-dgit will notice this and complain. You may have to fix these bugs
-before you can unify your existing git history with dgit's.
+For
+.BR ssh ,
+the default value is taken from the
+.B DGIT_SSH
+or
+.B GIT_SSH
+environment variables, if set (see below). And, for ssh, when accessing the
+archive and dgit-repos, this command line setting is overridden by the
+git config variables
+.BI dgit-distro. distro .ssh
+and
+.B .dgit.default.ssh
+(which can in turn be overridden with -c). Also, when dgit is using
+git to access dgit-repos, only git's idea of what ssh to use (eg,
+.BR GIT_SSH )
+is relevant.
+.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 --force- something
+Instructs dgit to try to proceed despite detecting
+what it thinks is going to be a fatal problem.
+.B This is probably not going to work.
+These options are provided as an escape hatch,
+in case dgit is confused.
+(They might also be useful for testing error cases.)
+.TP
+.B --import-dsc-with-dgit-field
+Tell dgit import-dsc to treat a .dsc with a Dgit field
+like one without it.
+The result is a fresh import,
+discarding the git history
+that the person who pushed that .dsc was working with.
+.TP
+.B --force-unrepresentable
+Carry on even if
+dgit thinks that your git tree contains changes
+(relative to your .orig tarballs)
+which dpkg-source is not able to represent.
+Your build or push will probably fail later.
+.TP
+.B --force-changes-origs-exactly
+Use the set of .origs specified in your .changes, exactly,
+without regard to what is in the archive already.
+The archive may well reject your upload.
+.TP
+.B --force-unsupported-source-format
+Carry on despite dgit not understanding your source package format.
+dgit will probably mishandle it.
+.TP
+.B --force-dsc-changes-mismatch
+Do not check whether .dsc and .changes match.
+The archive will probably reject your upload.
+.TP
+.BR --force-import-gitapply-absurd " | " --force-import-gitapply-no-absurd
+Force on or off the use of the absurd git-apply emulation
+when running gbp pq import
+when importing a package from a .dsc.
+See Debian bug #841867.