archive. (For a format `3.0 (quilt)' source package, dgit push
may also have to make a commit on your current branch to contain
quilt metadata. It will do this automatically.)
-.BR "debian/rules clean" .
+
+.B dgit quilt-fixup
+looks to see if there is quilt patch metadata left over by dpkg-source
+-b, and if so makes a git commit of it. This is normally done
+automatically by dgit push. dgit quilt-fixup takes no additional
+arguments. Note that it will only process a patch generated by
+dpkg-source for the most recent version (according to the
+debia/changelog).
.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
Secondly, you can 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. See also the BUGS section.
+export this patch stack. For `3.0 (quilt)' packages, dgit has to do
+more work to work around quilt braindamage. See also the BUGS
+section. We recommend against the use of `3.0 (quilt)'.
.SH OPTIONS
.TP
.BR --dry-run | -n
Doing this is made more complicated by the possibility of a `3.0
(quilt)' package with multiple .orig tarballs.
+`3.0 (quilt)' packages have an additional difficulty: if these are
+edited in the most normal way, and then fed to dpkg-buildpackage,
+dpkg-source will add extra quilt patch metadata to the source tree
+during the source package build. This extra metadata is then of
+course not included in the git history. So dgit push needs to commit
+it for you, to make sure that the git history and archive contents are
+identical. That this is necessary is a bug in the `3.0 (quilt)'
+format.
+
The error messages are often unhelpfully terse and tend to refer to
line numbers in dgit.