chiark / gitweb /
Import: Allow --force to enable/disable
[dgit.git] / dgit.1
diff --git a/dgit.1 b/dgit.1
index a015906..cc10695 100644 (file)
--- a/dgit.1
+++ b/dgit.1
@@ -376,7 +376,13 @@ maintainer view, the pseudo-merge will appear only in the dgit view.)
 Declare that you are deliberately doing
 .IR something .
 This can be used to override safety catches, including safety catches
-which relate to distro-specific policies.  The meanings of
+which relate to distro-specific policies.
+The use of --deliberately is declared and published in the signed tags
+generated for you by dgit,
+so that the archive software can give effect to your intent,
+and
+for the benefit humans looking at the history.
+The meanings of
 .IR something s
 understood in the context of Debian are discussed below:
 .TP
@@ -402,19 +408,35 @@ as the Debian server will do this automatically when necessary.
 .TP
 .BR --quilt=linear
 When fixing up source format `3.0 (quilt)' metadata, insist on
-generating a linear patch stack.  If such a stack cannot be generated,
-fail.  This is the default for Debian.
+generating a linear patch stack: one new patch for each relevant
+commit.
+If such a stack cannot be generated, fail.
+This is the default for Debian.
+
+HEAD should be a series of plain commits
+(not touching debian/patches/),
+and pseudomerges,
+with as ancestor a patches-applied branch.
 .TP
 .BR --quilt=auto
 When fixing up source format `3.0 (quilt)' metadata, prefer to
-generate a linear patch stack, but if that doesn't seem possible,
-generate a single squashed patch for all the changes made in git.
+generate a linear patch stack
+(as with --quilt=auto)
+but if that doesn't seem possible,
+try to generate a single squashed patch for all the changes made in git
+(as with --quilt=smash).
 This is not a good idea for an NMU in Debian.
 .TP
 .BR --quilt=smash
 When fixing up source format `3.0 (quilt)' metadata,
-generate a single squashed patch for all the changes made in git.
+generate a single additional patch for all the changes made in git.
 This is not a good idea for an NMU in Debian.
+
+(If HEAD has any in-tree patches already, they must apply cleanly.
+This will be the case for any trees produced by dgit fetch or clone;
+if you do not change the upstream version
+nor make changes in debian/patches,
+it will remain true.)
 .TP
 .BR --quilt=nofix
 Check whether source format `3.0 (quilt)' metadata would need fixing
@@ -429,20 +451,24 @@ Do not check whether up source format `3.0 (quilt)' metadata needs
 fixing up.  If you use this option and the metadata did in fact need
 fixing up, dgit push will fail.
 .TP
-.BR --quilt=gbp " | " --quilt=dpm " | " --quilt=unapplied
+.BR -- [ quilt= ] gbp " | " -- [ quilt= ] dpm " | " --quilt=unapplied
 Tell dgit that you are using a nearly-dgit-compatible git branch,
 aka a
 .BR "maintainer view" ,
 and
 do not want your branch changed by dgit.
 
-.B --quilt=gbp
+.B --gbp
+(short for
+.BR --quilt=gbp )
 is for use with git-buildpackage.
 Your HEAD is expected to be
 a patches-unapplied git branch, except that it might contain changes
 to upstream .gitignore files.  This is the default for dgit gbp-build.
 
-.B --quilt=dpm
+.B --dpm
+(short for
+.BR --quilt=dpm )
 is for use with git-dpm.
 Your HEAD is expected to be
 a patches-applied git branch,
@@ -453,30 +479,87 @@ specifies that your HEAD is a patches-unapplied git branch (and
 that any changes to upstream .gitignore files are represented as
 patches in debian/patches).
 
-Instead, dgit quilt-fixup and dgit-push will automatically
-convert your git branch into the right form,
-and dgit push will push the
+With --quilt=gbp|dpm|unapplied,
+dgit push (or precursors like quilt-fixup and build) will automatically
+generate a conversion of your git branch into the right form.
+dgit push will push the
 dgit-compatible form (the
 .BR "dgit view" )
 to the dgit git server.
 The dgit view will be visible to you
 in the dgit remote tracking branches, but your own branch will
 not be modified.
-dgit will create a tag
+dgit push will create a tag
 .BI debian/ version
 for the maintainer view, and the dgit tag
 .BI archive/debian/ version
 for the dgit view.
+dgit quilt-fixup will merely do some checks,
+and cache the maintainer view.
 
 .B If you have a branch like this it is essential to specify the appropriate --quilt= option!
 This is because it is not always possible to tell: a patches-unapplied
-git branch of a package with one patch, for example, looks just the
-same as a patches-applied branch where the user has used git revert to
+git branch of a package with one patch, for example, looks very like
+a patches-applied branch where the user has used git revert to
 undo the patch, expecting to actually revert it.
-If you fail to specify the right \-\-quilt option,
+However, if you fail to specify the right \-\-quilt option,
 and you aren't too lucky, dgit will notice the problem and stop,
 with a useful hint. 
 .TP
+.BR -d "\fIdistro\fR | " --distro= \fIdistro\fR
+Specifies that the suite to be operated on is part of distro
+.IR distro .
+This overrides the default value found from the git config option
+.BR dgit-suite. \fIsuite\fR .distro .
+The only effect is that other configuration variables (used
+for accessing the archive and dgit-repos) used are
+.BR dgit-distro. \fIdistro\fR .* .
+
+If your suite is part of a distro that dgit already knows about, you
+can use this option to make dgit work even if your dgit doesn't know
+about the suite.  For example, specifying
+.B -ddebian
+will work when the suite is an unknown suite in the Debian archive.
+
+To define a new distro it is necessary to define methods and URLs
+for fetching (and, for dgit push, altering) a variety of information both
+in the archive and in dgit-repos.
+How to set this up is not yet documented.
+.TP
+.BI -C changesfile
+Specifies the .changes file which is to be uploaded.  By default
+dgit push looks for single .changes file in the parent directory whose
+filename suggests it is for the right package and version.
+
+If the specified
+.I changesfile
+pathname contains slashes, the directory part is also used as
+the value for
+.BR --build-products-dir ;
+otherwise, the changes file is expected in that directory (by
+default, in
+.BR .. ).
+.TP
+.B --rm-old-changes
+When doing a build, delete any changes files matching
+.IB package _ version _*.changes
+before starting.  This ensures that
+dgit push (and dgit sbuild) will be able to unambigously
+identify the relevant changes files from the most recent build, even
+if there have been previous builds with different tools or options.
+The default is not to remove, but
+.B \-\-no-rm-old-changes
+can be used to override a previous \-\-rm-old-changes
+or the .rm-old-changes configuration setting.
+.TP
+.BI --build-products-dir= directory
+Specifies where to find the built files to be uploaded.
+By default, dgit looks in the parent directory
+.RB ( .. ).
+.TP
+.BI --no-rm-on-error
+Do not delete the destination directory if clone fails.
+.TP
 .BI -D
 Prints debugging information to stderr.  Repeating the option produces
 more output (currently, up to -DDDD is meaningfully different).
@@ -506,6 +589,55 @@ Passed to dpkg-genchanges (eventually).
 .RI \fB--ch:\fR option
 Specifies a single additional option to pass, eventually, to
 dpkg-genchanges.
+
+Options which are safe to pass include
+.BR "-si -sa -sd -C" .
+
+For other options the caveat below applies.
+.TP
+.RI \fB--curl:\fR option " | \fB--dput:\fR" option " |..."
+Specifies a single additional option to pass to
+.BR curl ,
+.BR dput ,
+.BR debsign ,
+.BR dpkg-source ,
+.BR dpkg-buildpackage ,
+.BR dpkg-genchanges ,
+.BR sbuild ,
+.BR ssh ,
+.BR dgit ,
+.BR gbp-pq ,
+.BR gbp-build ,
+or
+.BR mergechanges .
+Can be repeated as necessary.
+
+Use of this ability should not normally be necessary.
+It is provided for working around bugs,
+or other unusual situations.
+If you use these options,
+you may violate dgit's assumptions
+about the behaviour of its subprograms
+and cause lossage.
+
+For dpkg-buildpackage, dpkg-genchanges, mergechanges and sbuild,
+the option applies only when the program is invoked directly by dgit.
+Usually, for passing options to dpkg-genchanges, you should use
+.BR --ch: \fIoption\fR.
+
+Specifying --git is not effective for some lower-level read-only git
+operations performed by dgit, and also not when git is invoked by
+another program run by dgit.
+
+See notes below regarding ssh and dgit.
+
+NB that --gpg:option is not supported (because debsign does not
+have that facility).
+But see
+.B -k
+and the
+.B keyid
+distro config setting.
 .TP
 .RI \fB--curl=\fR program " | \fB--dput=\fR" program  " |..."
 Specifies alternative programs to use instead of
@@ -568,93 +700,6 @@ git to access dgit-repos, only git's idea of what ssh to use (eg,
 .BR GIT_SSH )
 is relevant.
 .TP
-.RI \fB--curl:\fR option " | \fB--dput:\fR" option " |..."
-Specifies a single additional option to pass to
-.BR curl ,
-.BR dput ,
-.BR debsign ,
-.BR dpkg-source ,
-.BR dpkg-buildpackage ,
-.BR dpkg-genchanges ,
-.BR sbuild ,
-.BR ssh ,
-.BR dgit ,
-.BR gbp-pq ,
-.BR gbp-build ,
-or
-.BR mergechanges .
-Can be repeated as necessary.
-
-For dpkg-buildpackage, dpkg-genchanges, mergechanges and sbuild,
-this applies only when the program is invoked directly by dgit.
-Usually, for passing options to dpkg-genchanges, you should use
-.BR --ch: \fIoption\fR.
-
-Specifying --git not effective for some lower-level read-only git
-operations performed by dgit, and also not when git is invoked by
-another program run by dgit.
-
-See notes above regarding ssh and dgit.
-
-NB that --gpg:option is not supported (because debsign does not
-have that facility).
-But see
-.B -k
-and the
-.B keyid
-distro config setting.
-.TP
-.BR -d "\fIdistro\fR | " --distro= \fIdistro\fR
-Specifies that the suite to be operated on is part of distro
-.IR distro .
-This overrides the default value found from the git config option
-.BR dgit-suite. \fIsuite\fR .distro .
-The only effect is that other configuration variables (used
-for accessing the archive and dgit-repos) used are
-.BR dgit-distro. \fIdistro\fR .* .
-
-If your suite is part of a distro that dgit already knows about, you
-can use this option to make dgit work even if your dgit doesn't know
-about the suite.  For example, specifying
-.B -ddebian
-will work when the suite is an unknown suite in the Debian archive.
-
-To define a new distro it is necessary to define methods and URLs
-for fetching (and, for dgit push, altering) a variety of information both
-in the archive and in dgit-repos.
-How to set this up is not yet documented.
-.TP
-.BI -C changesfile
-Specifies the .changes file which is to be uploaded.  By default
-dgit push looks for single .changes file in the parent directory whose
-filename suggests it is for the right package and version.
-
-If the specified
-.I changesfile
-pathname contains slashes, the directory part is also used as
-the value for
-.BR --build-products-dir ;
-otherwise, the changes file is expected in that directory (by
-default, in
-.BR .. ).
-.TP
-.B --rm-old-changes
-When doing a build, delete any changes files matching
-.IB package _ version _*.changes
-before starting.  This ensures that
-dgit push (and dgit sbuild) will be able to unambigously
-identify the relevant changes files from the most recent build, even
-if there have been previous builds with different tools or options.
-The default is not to remove, but
-.B \-\-no-rm-old-changes
-can be used to override a previous \-\-rm-old-changes
-or the .rm-old-changes configuration setting.
-.TP
-.BI --build-products-dir= directory
-Specifies where to find the built files to be uploaded.
-By default, dgit looks in the parent directory
-.RB ( .. ).
-.TP
 .BI --existing-package= package
 dgit push needs to canonicalise the suite name.  Sometimes, dgit
 lacks a way to ask the archive to do this without knowing the
@@ -677,8 +722,34 @@ removed and recreated before dgit starts, rather than removed
 after dgit finishes.  The directory specified must be an absolute
 pathname.
 .TP
-.BI --no-rm-on-error
-Do not delete the destination directory if clone fails.
+.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-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-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.
 .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
@@ -927,6 +998,7 @@ fetches may result in subsequent actions being different.  Doing a
 non-dry-run dgit fetch first will help.
 .SH SEE ALSO
 \fBdgit\fP(7),
+\fBdgit-maint-merge\fP(7),
 \fBcurl\fP(1),
 \fBdput\fP(1),
 \fBdebsign\fP(1),