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.
+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.)
+
+.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).
.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
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. See also the BUGS section.
+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)'.
.SH OPTIONS
.TP
.BR --dry-run | -n
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
-exists in the target suite. If it doesn't, you can use this option to
-specify a package which does. If the suite is empty, bad luck.
+or use the value of this option.
.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
.TP
.BI dgit.default.distro
.TP
-.BI dgit.default.username
+.BI dgit-distro. distro .username
.TP
.BI dgit-distro. distro .git-url
.TP
+.BI dgit-distro. distro .git-user
+.TP
.BI dgit-distro. distro .git-host
.TP
.BI dgit-distro. distro .git-proto
.TP
.BI dgit-distro. distro .archive-query-default-component
.TP
+.BI dgit-distro. distro .sshdakls-user
+.TP
+.BI dgit-distro. distro .sshdakls-host
+.TP
+.BI dgit-distro. distro .sshdakls-dir
+.TP
.BI dgit-distro. distro .ssh
.TP
.BR dgit.default. *
The method of canonicalising suite names is bizarre. See the
.B --existing-package
-option for one of the implication.s
+option for one of the implications.
dgit push should perhaps do `git push origin', or something similar,
by default.
+Debian does not have a working rmadison server, so to find out what
+version of a package is in the archive, or to canonicalise suite
+names, we ssh directly into the ftpmaster server.
+
The mechanism for checking for and creating per-package repos on
alioth is a hideous bodge. One consequence is that dgit currently
only works for people with push access.
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.
+
The error messages are often unhelpfully terse and tend to refer to
line numbers in dgit.
~ianmdlvl / dgit.git / blobdiff