fix bug which causes all uploads to go to sid (!)

[dgit.git] / dgit.1

diff --git a/dgit.1 b/dgit.1
index 652ffbb62bcca12b382947e453b3d815aec07d98..1abb7ecdc11480d587611eafd5e5373e4bf4aac6 100644 (file)
--- a/dgit.1
+++ b/dgit.1
@@ -12,7 +12,7 @@ dgit \- git integration with the Debian archive
 [\fIsuite\fP]
 .br
 .B dgit
 [\fIsuite\fP]
 .br
 .B dgit

-[\fIdgit\-opts\fP] \fBbuild\fP|\fBsbuild\fP
+[\fIdgit\-opts\fP] \fBbuild\fP|\fBsbuild\fP|\fBbuild-source\fP

 [\fIbuild\-opts\fp]
 .br
 .B dgit
 [\fIbuild\-opts\fp]
 .br
 .B dgit


@@ -33,9 +33,10 @@ as
 which lives outside the Debian archive (currently, on Alioth).
 
 The usual workflow is: 1. clone or fetch; 2. make and commit changes
 which lives outside the Debian archive (currently, on Alioth).
 
 The usual workflow is: 1. clone or fetch; 2. make and commit changes

-in git as desired; 3. run dgit build or dgit sbuild, or generate the
-source and binary packages for upload some other way; 4. do
-pre-upload tests of the proposed upload; 5. run dgit push.
+in git as desired; 3. run dgit build, dgit sbuild or dgit
+build-source, or generate the source and binary packages for upload
+some other way; 4. do pre-upload tests of the proposed upload; 5. run
+dgit push.

 .TP
 \fBdgit clone\fR \fIpackage\fP [\fIsuite\fP] [\fB./\fP\fIdir|\fB/\fP\fIdir\fR]
 Consults the archive and dgit-repos to construct the git view of
 .TP
 \fBdgit clone\fR \fIpackage\fP [\fIsuite\fP] [\fB./\fP\fIdir|\fB/\fP\fIdir\fR]
 Consults the archive and dgit-repos to construct the git view of


@@ -86,7 +87,22 @@ with some suitable options.  Options and argumments after build
 will be passed on to git-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
 will be passed on to git-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.  Tagging and signing should be left to dgit push.
+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
+.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
 .TP
 \fBdgit sbuild\fR ...
 Constructs the source package, and uses sbuild to do a binary


@@ -96,6 +112,8 @@ 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
 .B dgit push
 Does an `upload', pushing the current HEAD to the archive (as a source
 .TP
 .B dgit push
 Does an `upload', pushing the current HEAD to the archive (as a source


@@ -110,12 +128,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.
 


@@ -123,15 +135,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


@@ -256,15 +265,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


@@ -288,6 +316,21 @@ Specifies that we should process source package
 rather than looking in debian/control or debian/changelog.
 Valid with dgit fetch and dgit pull, only.
 .TP
 rather than looking in debian/control or debian/changelog.
 Valid with dgit fetch and dgit pull, only.
 .TP

+.BR --clean=git | -wg
+The source tree should be cleaned, before building a source package
+with one of the build options, using
+.BR "git clean -xdf" .
+This will delete all files which are not tracked by git.
+.TP
+.BR --clean=none | -wn
+Do not clean the tree before building a source package.  If there are
+files which are not in git, a subsequent dgit push will fail.
+.TP
+.BR --clean=dpkg-source | -wd
+Use dpkg-buildpackage to do the build, so that the source package
+is cleaned by dpkg-source running the package's clean target.
+This is the default.  It requires the package's build dependencies.
+.TP

 .BR -N | --new
 The package may be new in this suite.  Without this, dgit will
 refuse to push.
 .BR -N | --new
 The package may be new in this suite.  Without this, dgit will
 refuse to push.


@@ -300,26 +343,41 @@ more output (currently, up to -DD is meaningfully different).
 Specifies a git configuration option.  dgit itself is also controlled
 by git configuration options.
 .TP
 Specifies a git configuration option.  dgit itself is also controlled
 by git configuration options.
 .TP

+.RI \fB-v\fR version |\fB-m\fR maintaineraddress
+Passed to dpkg-genchanges (eventually).
+.TP
+.RI \fB--ch:\fR option
+Specifies a single additional option to pass, eventually, to
+dpkg-genchanges.
+.TP

 .RI \fB--dget=\fR program |\fB--dput=\fR program |...
 Specifies alternative programs to use instead of
 .BR dget ,
 .BR dput ,
 .BR debsign ,
 .RI \fB--dget=\fR program |\fB--dput=\fR program |...
 Specifies alternative programs to use instead of
 .BR dget ,
 .BR dput ,
 .BR debsign ,

-.BR dpkg-buildpackage
+.BR dpkg-source ,
+.BR dpkg-buildpackage ,
+.BR dpkg-genchanges ,

 .BR sbuild ,
 or
 .BR mergechanges .
 .BR sbuild ,
 or
 .BR mergechanges .

+This applies only when the program is invoked directly by dgit.

 .TP
 .RI \fB--dget:\fR option |\fB--dput:\fR option |...
 Specifies a single additional option to pass to
 .BR dget ,
 .BR dput ,
 .BR debsign ,
 .TP
 .RI \fB--dget:\fR option |\fB--dput:\fR option |...
 Specifies a single additional option to pass to
 .BR dget ,
 .BR dput ,
 .BR debsign ,

-.BR dpkg-buildpackage
+.BR dpkg-source ,
+.BR dpkg-buildpackage ,
+.BR dpkg-genchanges ,

 .BR sbuild ,
 or
 .BR mergechanges .
 Can be repeated as necessary.
 .BR sbuild ,
 or
 .BR mergechanges .
 Can be repeated as necessary.

+This applies only when the program is invoked directly by dgit.
+Usually, for passing options to dpkg-genchanges, use
+.BR --ch: \fIoption\fR.

 .TP
 .BR -d "\fIdistro\fR | " --distro= \fIdistro\fR
 Specifies that the suite to be operated on is part of distro
 .TP
 .BR -d "\fIdistro\fR | " --distro= \fIdistro\fR
 Specifies that the suite to be operated on is part of distro


@@ -465,14 +523,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