with some suitable options. Options and arguments after gbp-build
will be passed on to git-buildpackage.
+By default this uses \-\-quilt=gbp, so HEAD should be a
+git-buildpackage style branch, not a patches-applied branch.
+
Tagging, signing and actually uploading should be left to dgit push.
.TP
\fBdgit push\fR [\fIsuite\fP]
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 --overwrite= previous-version
-Declare that even though your git branch is not a descendant of
-.IR previous-version
-according to the revision history, in fact, it really does contain
+.BR --overwrite =\fIprevious-version\fR
+Declare that even though your git branch is not a descendant
+of the version in the archive
+according to the revision history,
+it really does contain
all the (wanted) changes from that version.
-.I previous-version
-ought to be the version currently in the archive.
-dgit push will make a
+This option is useful if you are the maintainer, and you have
+incorporated NMU changes into your own git workflow in a way that
+doesn't make your branch a fast forward from the NMU.
+
+.I previous-version
+ought to be the version currently in the archive. If
+.I previous-version
+is not
+specified, dgit will check that the version in the archive is
+mentioned in your debian/changelog.
+(This will avoid losing
+changes unless someone committed to git a finalised changelog
+entry, and then made later changes to that version.)
+
+dgit push --overwrite
+will make a
pseudo-merge (that is, something that looks like the result
of git merge -s ours) to stitch the archive's version into your own
git history, so that your push is a fast forward from the archive.
-This option is useful if you are the maintainer, and you have
-incorporated NMU changes into your own git workflow in way that
-doesn't make your branch a fast forward from the NMU.
-
(In quilt mode
.BR gbp ", " dpm " or " unpatched ,
implying a split between the dgit view and the
fixing up. If you use this option and the metadata did in fact need
fixing up, dgit push will fail.
.TP
+.BR --quilt=gbp " | " --quilt=dpm " | " --quilt=unapplied
+Tell dgit that you are using a nearly-dgit-compatible git branch,
+aka a
+.BR "maintainer view" ,
+and
+do not want your branch changed by dgit.
+
+.B --quilt=gbp
+is for use with git-buildpackage.
+Your HEAD is expected to be
+a patches-unapplied git branch, except that it might contain changes
+to upstream .gitignore files. This is the default for dgit gbp-build.
+
+.B --quilt=dpm
+is for use with git-dpm.
+Your HEAD is expected to be
+a patches-applied git branch,
+except that it might contain changes to upstream .gitignore files.
+
+.B --quilt=unapplied
+specifies that your HEAD is a patches-unapplied git branch (and
+that any changes to upstream .gitignore files are represented as
+patches in debian/patches).
+
+Instead, dgit quilt-fixup and dgit-push will automatically
+convert your git branch into the right form,
+and dgit push will push the
+dgit-compatible form (the
+.BR "dgit view" )
+to the dgit git server.
+The dgit view will be visible to you
+in the dgit remote tracking branches, but your own branch will
+not be modified.
+dgit will create a tag
+.BI debian/ version
+for the maintainer view, and the dgit tag
+.BI archive/debian/ version
+for the dgit view.
+
+.B If you have a branch like this it is essential to specify the appropriate --quilt= option!
+This is because it is not always possible to tell: a patches-unapplied
+git branch of a package with one patch, for example, looks just the
+same as a patches-applied branch where the user has used git revert to
+undo the patch, expecting to actually revert it.
+If you fail to specify the right \-\-quilt option,
+and you aren't too lucky, dgit will notice the problem and stop,
+with a useful hint.
+.TP
.BI -D
Prints debugging information to stderr. Repeating the option produces
more output (currently, up to -DDDD is meaningfully different).
.BR ssh ,
.BR dgit ,
.BR git ,
+.BR gbp-pq ,
+.BR gbp-build ,
or
.BR mergechanges .
-For dpkg-buildpackage, dpkg-genchanges, mergechanges and sbuild,
+For
+.BR dpkg-buildpackage ,
+.BR dpkg-genchanges ,
+.B mergechanges
+and
+.BR sbuild ,
this applies only when the program is invoked directly by dgit.
-For dgit, specifies the command to run on the remote host when dgit
+For
+.BR dgit ,
+specifies the command to run on the remote host when dgit
rpush needs to invoke a remote copy of itself. (dgit also reinvokes
itself as the EDITOR for dpkg-source --commit; this is done using
argv[0], and is not affected by --dgit=).
-For ssh, the default value is taken from the
+.BR gbp-build 's
+value
+is used instead of gbp build or git-buildpackage. (The default is
+the latter unless the former exists on PATH.)
+.BR gbp-pq 's
+value
+is used instead of gbp pq.
+In both cases,
+unusually, the specified value is split on whitespace
+to produce a command and possibly some options and/or arguments.
+
+For
+.BR ssh ,
+the default value is taken from the
.B DGIT_SSH
or
.B GIT_SSH
.BR sbuild ,
.BR ssh ,
.BR dgit ,
+.BR gbp-pq ,
+.BR gbp-build ,
or
.BR mergechanges .
Can be repeated as necessary.
tracking branch. Then somehow, using your other git history
plus appropriate diffs and cherry picks from the dgit remote tracking
branch, construct a git commit whose tree corresponds to the tree to use for the
-next upload. If that commit-to-be-uploaded is not a descendant of the
-dgit remote tracking branch, check it out and say
-.BR "git merge -s ours remotes/dgit/dgit/" \fIsuite\fR;
-that tells git that we are deliberately throwing away any differences
+next upload.
+
between what's in the archive and what you intend to upload.
Then run
.BR "dgit push"
to actually upload the result.
+
+If the commit-to-be-uploaded is not a descendant of the
+dgit remote tracking branch, you will need to pass
+.B --overwrite
+to dgit.
.SH CONFIGURATION
dgit can be configured via the git config system.
You may set keys with git-config (either in system-global or per-tree