belongs.
.I suite
-may be
-.IR mainsuite \fB,\fR subsuite ...
-in which case dgit will synthesize a view giving the most
-recent version in any of the specified suites.
-(The subsuites do not need to have the package.)
-If a subsuite starts with
-.B -
-then mainsuite is prepended.
-Each of the suite names will be individually canonicalised
-to calculate the canonical branch names to use.
-When using this facility, it is important to always specify the
-same suites in the same order:
-dgit will not be make a coherent fast-forwarding history
-view otherwise.
+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
.IR suite ;
otherwise it parses debian/changelog and uses the suite specified
there.
-
-suite may be
-.IR mainsuite \fB,\fR subsuite ...
-as for clone.
+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
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