Document that dgit repos are cloneable with git, in dgit(1) section MODEL. [Andreas...

[dgit.git] / dgit.1

diff --git a/dgit.1 b/dgit.1
index 72b16a05ba79dbfd528073ddc84a50bdeb54657f..9705f0af2403abc84d2a07f07410dd6fb80125b0 100644 (file)
--- a/dgit.1
+++ b/dgit.1
@@ -167,7 +167,17 @@ Pushes the contents of the specified directory on a remote machine.
 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
@@ -586,6 +596,10 @@ directory, as with a traditional (non-gitish) dpkg-source workflow.
 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.