Diffstat (limited to 'dgit.1')
1 files changed, 89 insertions, 25 deletions
@@ -18,6 +18,9 @@ dgit \- git integration with the Debian archive
[\fIdgit\-opts\fP] \fBpush\fP [\fIdgit\-opts\fP]
+[\fIdgit\-opts\fP] \fIaction\fR ...
treats the Debian archive as a version control system, and
@@ -29,40 +32,91 @@ as
which lives outside the Debian archive (currently, on Alioth).
-.B dgit clone
-.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
+\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
+.RB ( sid
+in a new directory (named
+.BI ./ package
+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.
+remote will be set up to point to the package's dgit-repos tree
+for the distro to which
+\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
+\fBdgit pull\fR [\fIsuite\fP]
+Does dgit fetch, and then merges the new head of the remote tracking
+.BI remotes/dgit/ suite
+into the current branch.
+\fBdgit build\fR ...
-with some suitable options. Options after
+with some suitable options. Options and argumments after
-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.
.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
+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 push always uses the package, suite and version specified in the
+debian/changelog and the .dsc, which must agree.
.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
+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
@@ -138,6 +192,11 @@ However, it is perfectly fine to have other branches in dgit-repos;
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
dgit push can operate on any commit which is a descendant of the
current dgit/suite tip in dgit-repos.
@@ -188,8 +247,9 @@ 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 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)'.
.BR --dry-run | -n
@@ -366,6 +426,10 @@ 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