chiark / gitweb /
Convert to defvalopt: --existing-package
[dgit.git] / dgit.7
diff --git a/dgit.7 b/dgit.7
index 6c74f40d46b4ed789b234e155f17dec0cf38ba54..a9886563eae90110f0f560bb2f73ed17fed3adf7 100644 (file)
--- a/dgit.7
+++ b/dgit.7
@@ -10,7 +10,7 @@ augmented by commits representing uploads done by other developers not
 using dgit.  This git history is stored in a canonical location known
 as
 .B dgit-repos
-which lives outside the Debian archive (currently, on Alioth).
+which lives on a dedicated git server.
 .SH MODEL
 You may use any suitable git workflow with dgit, provided you
 satisfy dgit's requirements:
@@ -31,10 +31,10 @@ However, it is perfectly fine to have other branches in dgit-repos;
 normally the dgit-repos repo for the package will be accessible via
 the remote name `origin'.
 
-dgit push will also (by default) make signed tags called
+dgit push will also make signed tags called
 .BI debian/ version
-and push them to dgit-repos, but nothing depends on these tags
-existing.
+(a la DEP-14) and push them to dgit-repos.  These are used at the
+server to authenticate pushes.
 
 dgit push can operate on any commit which is a descendant of the
 current dgit/suite tip in dgit-repos.
@@ -64,7 +64,7 @@ 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
+only exception is that for sourceful 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