finalise 0.11

[dgit.git] / dgit.1

diff --git a/dgit.1 b/dgit.1
index 322bc3b0ab27862663bc302da08a52cae2d71206..9740856b215a59d62c8790743b3cb2faa2d2b023 100644 (file)
--- a/dgit.1
+++ b/dgit.1
@@ -82,22 +82,20 @@ into the current branch.
 .TP
 \fBdgit build\fR ...
 Runs
 .TP
 \fBdgit build\fR ...
 Runs

-.B git-buildpackage
+.B dpkg-buildpackage

 with some suitable options.  Options and argumments after build
 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.
 
 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
 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.
 .IR package \fB_\fR version \fB.dsc\fR
 and
 .IR package \fB_\fR version \fB_source.changes\fR.


@@ -105,14 +103,23 @@ and
 Tagging, signing and actually uploading should be left to dgit push.
 .TP
 \fBdgit sbuild\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.
 
 .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
 Tagging, signing and actually uploading should be left to dgit push.
 .TP
 .B dgit push


@@ -128,12 +135,6 @@ field, runs debsign to sign the upload (.dsc and .changes), pushes the
 signed tag, and finally uses dput to upload the .changes to the
 archive.
 
 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.
 
 dgit push always uses the package, suite and version specified in the
 debian/changelog and the .dsc, which must agree.
 


@@ -141,15 +142,12 @@ If dgit push fails while uploading, it is fine to simply retry the
 dput on the .changes file at your leisure.
 .TP
 .B dgit quilt-fixup
 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
 .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


@@ -274,15 +272,34 @@ 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
 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
 .SH OPTIONS
 .TP
 .BR --dry-run | -n


@@ -513,14 +530,10 @@ the .orig.tar.gz could be transported via the git repo as git tags.
 Doing this is made more complicated by the possibility of a `3.0
 (quilt)' package with multiple .orig tarballs.
 
 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
 
 There should be an option which arranges for the `3.0 (quilt)'
 autocommit to not appear on your HEAD, but instead only in the