dgit-user(7) for users: editing, building and sharing packages
dgit-nmu-simple(7) for DDs: doing a straightforward NMU
dgit-maint-native(7) for maintainers of Debian-native packages
-dgit-maint-merge(7) for maintainers: using a merging git workflow
-dgit-maint-gbp(7) for maintainers: using git-buildpackage
+dgit-maint-merge(7) for maintainers who want a pure git workflow
+dgit-maint-gbp(7) for maintainers already using git-buildpackage
dgit-sponsorship(7) for sponsors and sponsored contributors
.TE
.LP
.I suite
belongs.
+.I suite
+may be a combination of several underlying suites in the form
+.IR mainsuite \fB,\fR subsuite ...;
+see COMBINED SUITES in dgit(7).
+
For your convenience, the
.B vcs-git
remote will be set up from the package's Vcs-Git field, if there is
.IR suite ;
otherwise it parses debian/changelog and uses the suite specified
there.
+suite may be a combined suite, as for clone.
.TP
\fBdgit pull\fR [\fIsuite\fP]
Does dgit fetch, and then merges the new head of the remote tracking
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,
+adjusts the .changes to include any .origs which the archive lacks
+and exclude .origs which the archive has
+(so -sa and -sd are not needed when building for dgit push),
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
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:
+.TS
+l l.
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.
+.TE
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
linearisation of your history, by default it will fail, but you can
ask it to generate a single squashed patch instead.
.TP
+\fBdgit import-dsc\fR [\fIsub-options\fR] \fI../path/to/.dsc\fR [\fB+\fR|\fB..\fR]branch
+Import a Debian-format source package,
+specified by its .dsc,
+into git,
+the way dgit fetch would do.
+
+This does about half the work of dgit fetch:
+it will convert the .dsc into a new, orphan git branch.
+Since dgit has no access to a corresponding source package archive
+or knowledge of the history
+it does not consider whether this version is newer
+than any previous import
+or corresponding git branches;
+and it therefore does not
+make a pseudomerge to bind the import
+into any existing git history.
+
+There is only only sub-option:
+
+.B --require-valid-signature
+causes dgit to insist that the signature on the .dsc is valid
+(using the same criteria as dpkg-source -x).
+Otherwise, dgit tries to verify the signature but
+the outcome is reported only as messages to stderr.
+
+If
+.I branch
+is prefixed with
+.B +
+then if it already exists, it will be simply ovewritten,
+no matter its existing contents.
+If
+.I branch
+is prefixed with
+.B ..
+then if it already exists
+and dgit actually imports the dsc
+(rather than simply reading the git commit out of the Dgit field),
+dgit will make a pseudomerge
+so that the result is necessarily fast forward
+from the existing branch.
+Otherwise, if branch already exists,
+dgit will stop with an error message.
+
+If
+.I branch
+does not start with refs/, refs/heads/ is prepended.
+The specified branch is unconditionally updated.
+
+If the specified .dsc contains a Dgit field,
+dgit will simply make a branch of that commit.
+If you cannot manage to find that commit anywhere,
+consider --force-import-dsc-with-dgit-field.
+.TP
.B dgit version
Prints version information and exits.
.TP
implying a split between the dgit view and the
maintainer view, the pseudo-merge will appear only in the dgit view.)
.TP
+.BR --delayed =\fIdays\fR
+Upload to a DELAYED queue.
+
+.B WARNING:
+If the maintainer responds by cancelling
+your upload from the queue,
+and does not make an upload of their own,
+this will not rewind the git branch on the dgit git server.
+Other dgit users will then see your push
+(with a warning message from dgit)
+even though the maintainer wanted to abolish it.
+Such users might unwittingly reintroduce your changes.
+
+If this situation arises,
+someone should make a suitable dgit push
+to update the contents of dgit-repos
+to a version without the controversial changes.
+.TP
+.BR --dgit-view-save= \fIbranch\fR|\fIref\fR
+Specifies that when a split view quilt mode is in operation,
+and dgit calculates
+(or looks up in its cache)
+a dgit view corresponding to your HEAD,
+the dgit view will be left in
+.IR ref .
+The specified ref is unconditionally overwritten,
+so don't specify a branch you want to keep.
+
+This option is effective only with the following operations:
+quilt-fixup; push; all builds.
+And it is only effective with
+--[quilt=]gbp,
+--[quilt=]dpm,
+--quilt=unpatched.
+
+If ref does not start with refs/
+it is taken to to be a branch -
+i.e. refs/heads/ is prepended.
+.TP
.BI --deliberately- something
Declare that you are deliberately doing
.IR something .
.BI --no-rm-on-error
Do not delete the destination directory if clone fails.
.TP
+.BI --dep14tag
+Generates a DEP-14 tag (eg
+.BR debian/ \fIversion\fR)
+as well as a dgit tag (eg
+.BR archive/debian/ \fIversion\fR)
+where possible. This is the default.
+.TP
+.BI --no-dep14tag
+Do not generate a DEP-14 tag, except in split quilt view mode.
+(On servers where only the old tag format is supported,
+the dgit tag will have the DEP-14 name.
+This option does not prevent that.)
+.TP
+.BI --dep14tag-always
+Insist on generating a DEP-14 tag
+as well as a dgit tag.
+If the server does not support that, dgit push will fail.
+.TP
.BI -D
Prints debugging information to stderr. Repeating the option produces
more output (currently, up to -DDDD is meaningfully different).
dpkg-genchanges.
Options which are safe to pass include
-.BR "-si -sa -sd -C" .
+.BR -C
+(and also
+.BR "-si -sa -sd"
+although these should never be necessary with Debian since dgit
+automatically calculates whether .origs need to be uploaded.)
For other options the caveat below applies.
.TP
.BR sbuild ,
.BR ssh ,
.BR dgit ,
+.BR apt-get ,
+.BR apt-cache ,
.BR gbp-pq ,
.BR gbp-build ,
or
.BR gpg ,
.BR ssh ,
.BR dgit ,
+.BR apt-get ,
+.BR apt-cache ,
.BR git ,
.BR gbp-pq ,
.BR gbp-build ,
in case dgit is confused.
(They might also be useful for testing error cases.)
.TP
+.B --import-dsc-with-dgit-field
+Tell dgit import-dsc to treat a .dsc with a Dgit field
+like one without it.
+The result is a fresh import,
+discarding the git history
+that the person who pushed that .dsc was working with.
+.TP
.B --force-unrepresentable
Carry on even if
dgit thinks that your git tree contains changes
which dpkg-source is not able to represent.
Your build or push will probably fail later.
.TP
+.B --force-changes-origs-exactly
+Use the set of .origs specified in your .changes, exactly,
+without regard to what is in the archive already.
+The archive may well reject your upload.
+.TP
.B --force-unsupported-source-format
Carry on despite dgit not understanding your source package format.
dgit will probably mishandle it.
Specifies the distro for a suite. dgit keys off the suite name (which
appears in changelogs etc.), and uses that to determine the distro
which is involved. The config used is thereafter that for the distro.
+
+.I suite
+may be a glob pattern.
.TP
.BI dgit.default.distro " distro"
The default distro for an unknown suite.
.TP
.BI dgit-distro. distro .dgit-tag-format
.TP
+.BR dgit-distro. \fIdistro\fR .dep14tag " " want | no | always
+.TP
.BI dgit-distro. distro .ssh
.TP
.BI dgit-distro. distro .sshpsql-dbname