.TP
\fBdgit build\fR ...
Runs
-.B git-buildpackage
+.B dpkg-buildpackage
with some suitable options. Options and argumments after build
-will be passed on to git-buildpackage. It is not necessary to use
+will be passed on to dpkg-buildpackage. It is not necessary to use
dgit build when using dgit; it is OK to use any approach which ensures
that the generated source package corresponds to the relevant git
commit.
-.B NB
-that this function will be changed in the future to use
-dpkg-buildpackage directly.
-
Tagging, signing and actually uploading should be left to dgit push.
.TP
\fBdgit build-source\fR ...
Builds the source package, and a changes file for a prospective
-source-only upload. The output is left in
+source-only upload, using
+.BR dpkg-source .
+The output is left in
.IR package \fB_\fR version \fB.dsc\fR
and
.IR package \fB_\fR version \fB_source.changes\fR.
Tagging, signing and actually uploading should be left to dgit push.
.TP
\fBdgit sbuild\fR ...
-Constructs the source package, and uses sbuild to do a binary
-build, and uses mergechanges to merge the source and binary
-changes files. Options and argumments after sbuild will be passed on
-to sbuild. Changes files matching
+Constructs the source package, uses
+.B sbuild
+to do a binary build, and uses mergechanges to merge the source and
+binary changes files. Options and argumments after sbuild will be
+passed on to sbuild. Changes files matching
.IB package _ version _*.changes
in the parent directory will be removed; the output is left in
.IR package \fB_\fR version \fB_multi.changes\fR.
+Tagging, signing and actually uploading should be left to dgit push.
+.TP
+\fBdgit git-build\fR ...
+Runs
+.B git-buildpackage
+with some suitable options. Options and argumments after git-build
+will be passed on to git-buildpackage.
+
Tagging, signing and actually uploading should be left to dgit push.
.TP
.B dgit push
signed tag, and finally uses dput to upload the .changes to the
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 if necessary.
-You can explicitly request that dgit do just this
-dgit quilt-fixup.
-
dgit push always uses the package, suite and version specified in the
debian/changelog and the .dsc, which must agree.
dput on the .changes file at your leisure.
.TP
.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).
-
-It is not normally necessary to run dgit quilt-fixup explicitly;
-where necessary it is done as part of dgit push.
+Looks to see if the tree is one which dpkg-source cannot properly
+represent. If it isn't, dgit will fix it up for you (in quilt terms,
+by making a new debian/ patch containing your unquilty changes) and
+make a commit of the changes it has made.
+
+This is normally done automatically by dgit build and dgit push.
.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
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. In the archive, the delta between upstream will be
-represented in the single Debian patch.
-
-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. For `3.0 (quilt)' packages, dgit has to do
-more work to work around some braindamage in way dpkg-source handles
-changes made to this format. See also the BUGS section. We recommend
-against the use of `3.0 (quilt)'.
+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 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.
+dgit's build functions, and dgit push, should not make any changes to
+your current HEAD. Sadly this is necessary for packages in the `3.0
+(quilt)' source format. This is ultimately due to design problems in
+quilt and dpkg-source.
There should be an option which arranges for the `3.0 (quilt)'
autocommit to not appear on your HEAD, but instead only in the
~ianmdlvl / dgit.git / blobdiff