-.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 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 MODEL
-You may use any suitable git workflow with dgit, provided you
-satisfy dgit's requirements:
-
-dgit maintains a pseudo-remote called
-.BR dgit ,
-with one branch per suite. This remote cannot be used with
-plain git.
-
-The
-.B dgit-repos
-repository for each package contains one ref per suite named
-\fBrefs/dgit/\fR\fIsuite\fR. These should be pushed to only by
-dgit. They are fast forwarding. Each push on this branch
-corresponds to an upload (or attempted upload).
-
-However, it is perfectly fine to have other branches in dgit-repos;
-normally the dgit-repos repo for the package will be accessible via
-the remote name `origin'.
-
-dgit push will also (by default) make signed tags called
-.BI debian/ version
-and push them to dgit-repos, but nothing depends on these tags
-existing.
-
-dgit push can operate on any commit which is a descendant of the
-current dgit/suite tip in dgit-repos.
-
-Uploads made by dgit contain an additional field
-.B Dgit
-in the source package .dsc. (This is added by dgit push.)
-This specifies a commit (an ancestor of the dgit/suite
-branch) whose tree is identical to the unpacked source upload.
-
-Uploads not made by dgit are represented in git by commits which are
-synthesised by dgit. The tree of each such commit corresponds to the
-unpacked source; there is an origin commit with the contents, and a
-psuedo-merge from last known upload - that is, from the contents of
-the dgit/suite branch.
-
-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. The
-orig tarballs are downloaded (by dgit clone) into the parent
-directory, as with a traditional (non-gitish) dpkg-source workflow.
-You need to retain these tarballs in the parent directory for dgit
-build and dgit push.
-
-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 READ-ONLY DISTROS
-Distros which do not maintain a set of dgit history git repositories
-can still be used in a read-only mode with dgit. Currently Ubuntu
-is configured this way.
-.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.
+.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 --force-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.