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.
+left in the parent directory. It is normally best to do the build
+with dgit too (eg with dgit sbuild): some existing build tools pass
+unhelpful options to dpkg-source et al by default, which can result in
+the built source package not being identical to the git tree.
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,
This is like running dgit push on build-host with build-dir as the
current directory; however, signing operations are done on the
invoking host. This allows you to do a push when the system which has
-the source code and the build outputs has no access to the key.
+the source code and the build outputs has no access to the key:
+
+1. Clone on build host (dgit clone)
+.br
+2. Edit code on build host (edit, git commit)
+.br
+3. Build package on build host (dgit build)
+.br
+4. Test package on build host or elsewhere (dpkg -i, test)
+.br
+5. Upload by invoking dgit rpush on host with your GPG key.
However, the build-host must be able to ssh to the dgit repos. If
this is not already the case, you must organise it separately, for
.TP
.B dgit version
Prints version information and exits.
+.TP
+.BI "dgit clone-dgit-repos-server" " destdir"
+Tries to fetch a copy of the source code for the dgit-repos-server,
+as actually being used on the dgit git server, as a git tree.
.SH OPTIONS
.TP
.BR --dry-run | -n
push will still ensure that the .dsc you upload and the git tree
you push are identical, so this option won't make broken pushes.)
.TP
+.BI --deliberately- something
+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
+.IR something s
+understood in the context of Debian are discussed below:
+.TP
+.BR --deliberately-not-fast-forward
+Declare that you are deliberately rewinding history. When pushing to
+Debian, use this when you are making a renewed upload of an entirely
+new source package whose previous version was not accepted for release
+from NEW because of problems with copyright or redistributibility.
+.TP
+.BR --deliberately-include-questionable-history
+Declare that you are deliberately including, in the git history of
+your current push, history which contains a previously-submitted
+version of this package which was not approved (or has not yet been
+approved) by the ftpmasters. When pushing to Debian, only use this
+option after verifying that: none of the rejected-from-NEW (or
+never-accepted) versions in the git history of your current push, were
+rejected by ftpmaster for copyright or redistributability reasons.
+.TP
+.BR --deliberately-fresh-repo
+Declare that you are deliberately rewinding history and want to
+throw away the existing repo. Not relevant when pushing to Debian,
+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,
You need to retain these tarballs in the parent directory for dgit
build and dgit push.
+dgit repositories could be cloned with standard (git) methods. The
+only exception is that for sourcefull builds / uploads the orig
+tarball(s) need to be present in the parent directory.
+
To a user looking at the archive, changes pushed using dgit look like
changes made in an NMU: in a `3.0 (quilt)' package the delta from the
previous upload is recorded in a new patch constructed by dpkg-source.
~ianmdlvl / dgit.git / blobdiff