.B dgit
[\fIdgit\-opts\fP] \fBpush\fP [\fIdgit\-opts\fP]
[\fIsuite\fP]
+.br
+.B dgit
+[\fIdgit\-opts\fP] \fIaction\fR ...
.SH DESCRIPTION
.B dgit
treats the Debian archive as a version control system, and
.B dgit-repos
which lives outside the Debian archive (currently, on Alioth).
-.B dgit clone
-and
-.B dgit fetch
-consult the archive and dgit-repos and fetch and/or construct the
-git view of the history. With clone, the destination directory (by
-default, the package name in the current directory) will be created,
-and the new directory's `origin' remote will be set up to point to
-the package's dgit-repos tree.
-
-.B dgit build
-runs
+.TP
+\fBdgit clone\fR \fIpackage\fP [\fIsuite\fP] [\fB./\fP\fIdir|\fB/\fP\fIdir]
+Consults the archive and dgit-repos to construct the git view of
+history for
+.I package
+in
+.I suite
+.RB ( sid
+by default)
+in a new directory (named
+.BI ./ package
+by default);
+also, downloads any necessary orig tarballs.
+
+The suite's git tip is
+left on the local branch
+.BI dgit/ suite
+ready for work, and on the corresponding dgit remote tracking branch.
+Also, the
+.B origin
+remote will be set up to point to the package's dgit-repos tree
+for the distro to which
+.I suite
+belongs.
+.TP
+\fBdgit fetch\fR [\fIsuite\fP]
+Consults the archive and git-repos to update the git view of
+history for a specific suite (and downloads any necessary orig
+tarballs), and updates the remote tracking branch
+.BR remotes/dgit/ \fIsuite\fR.
+If the current branch is
+.BI dgit/ suite
+then dgit fetch defaults to
+.IR suite ;
+otherwise it parses debian/changelog and uses the suite specified
+there.
+.TP
+\fBdgit pull\fR [\fIsuite\fP]
+Does dgit fetch, and then merges the new head of the remote tracking
+branch
+.BI remotes/dgit/ suite
+into the current branch.
+.TP
+\fBdgit build\fR ...
+Runs
.B git-buildpackage
-with some suitable options. Options after
+with some suitable options. Options and argumments after
.B build
-will be passed on to git-buildpackage. It is not necessary to
-use dgit build; 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.
-
+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.
+.TP
.B dgit push
-does an `upload', pushing the current HEAD to the archive (as a source
-package) and to dgit-repos (as git commits). This also involves
-making a signed git tag, and signing the files to be uploaded to the
-archive. (For a format `3.0 (quilt)' source package, dgit push
+Does an `upload', pushing the current HEAD to the archive (as a source
+package) and to dgit-repos (as git commits). The package must already
+have been built ready for upload, with the .dsc and .changes
+left in the parent directory.
+
+In more detail: dgit push checks that the current HEAD corresponds to
+the .dsc. It then pushes the HEAD to the suite's dgit-repos branch,
+makes a signed git tag, edits the .dsc to contain the dgit metadata
+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.
+
+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.)
+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.
+.TP
.B dgit quilt-fixup
-looks to see if there is quilt patch metadata left over by dpkg-source
+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.
.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
normally the dgit-repos repo for the package will be accessible via
the remote name `origin'.
+dgit push will also (by default) make signed tags called
+.BI debian/ version
+and push them to dgit-repos, but nothing depends on these tags
+existing.
+
dgit push can operate on any commit which is a descendant of the
current dgit/suite tip in dgit-repos.
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 quilt braindamage. See also the BUGS
-section. We recommend against the use of `3.0 (quilt)'.
+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)'.
.SH OPTIONS
.TP
.BR --dry-run | -n
identical. That this is necessary is a bug in the `3.0 (quilt)'
format.
+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.
+
+There should at the very least be some advice in the manpage about how
+to use dgit when the signing key is not available on the same machine
+as the build host.
+
The option parser requires values to be cuddled to the option name.
dgit assumes knowledge of the archive layout. There appears to be no