chiark / gitweb /
Better error checking when parsing RFC822-style control data.
[dgit.git] / dgit.1
diff --git a/dgit.1 b/dgit.1
index 9e5cf538c62c93270522cd51331729399dc762f2..f850924e2e00eba0cde22ab52a11b84ff7d5b607 100644 (file)
--- a/dgit.1
+++ b/dgit.1
@@ -104,12 +104,12 @@ working branches
 If last upload was not made with git, a different approach is required
 to start using dgit.  First, do
 .B dgit fetch
-(or clone) obtain a git history representation of what's in the
+(or clone) to obtain a git history representation of what's in the
 archive and record it in the
 .BI remotes/dgit/ suite
-tracking branch.  Then construct somehow, using your other git history
+tracking branch.  Then somehow, using your other git history
 plus appropriate diffs and cherry picks from the dgit remote tracking
-branch, a git commit whose tree corresponds to the tree to use for the
+branch, construct a git commit whose tree corresponds to the tree to use for the
 next upload.  If that commit-to-be-uploaded is not a descendant of the
 dig remote tracking branch, check it out and say
 .BR "git merge -s ours remotes/dgit/" \fIsuite\fR;
@@ -243,7 +243,21 @@ dgit push needs to canonicalise the suite name.  But currently
 there is no way to ask the archive to do this without knowing the
 name of an existing package.  Without --new we can just use the
 package we are trying to push.  But with --new that will not work, so
-we guess that
+we guess
+.B dpkg
+or use the value of this option.
+.TP
+.BR -h | --help
+Print a usage summary.
+.SH SEE ALSO
+\fBdget\fP(1),
+\fBdput\fP(1),
+\fBdebsign\fP(1),
+\fBgit-config\fP(1),
+\fBgit-buildpackage\fP(1),
+\fBdpkg-buildpackage\fP(1),
+.br
+https://wiki.debian.org/Alioth
 .SH CONFIGURATION
 dgit looks at the following git config keys to control its behaviour.
 You may set them with git-config (either in system-global or per-tree
@@ -348,8 +362,9 @@ 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.
+There should be an option which arranges for the `3.0 (quilt)'
+autocommit to not appear on your HEAD, but instead only in the
+remote tracking suite branch.
 
 The option parser requires values to be cuddled to the option name.