documentation style: "appropriate configuration" as a mass noun

[dgit.git] / dgit-sponsorship.7.pod

diff --git a/dgit-sponsorship.7.pod b/dgit-sponsorship.7.pod
index ed37ff5f1107956f49536a93850d52778ea28b81..2e6f82d95071c74cc55033b03a73f56a15111aae 100644 (file)
--- a/dgit-sponsorship.7.pod
+++ b/dgit-sponsorship.7.pod
@@ -9,7 +9,7 @@ and
 a sponsoring DD (or DM)
 can collaborate and publish using git.
 
-The sponsor must to be intending to use dgit for the upload.
+The sponsor must be intending to use dgit for the upload.
 (If the sponsor does not use dgit,
 it is not possible to properly publish
 a sponsee's git branch.)
@@ -30,7 +30,7 @@ This section is addressed to the sponsee:
 =head2 General
 
 You should prepare the package as if you were going
-to upload it with C<dgit push> yourself.
+to upload it with C<dgit push-source> or C<dgit push> yourself.
 
 For a straightforward NMU, consult L<dgit-nmu-simple(7)>.
 
@@ -102,13 +102,11 @@ against the sponsorship-requests pseudo-package.
 The sponsee should push their HEAD as a git branch
 to any suitable git server.
 They can use their own git server;
-alioth is another possibility.
+salsa is another possibility.
 
 The branch names used by the sponsee on their local machine,
 and on the server, do not matter.
 
-The sponsee should not make a C<debian/>I<version> tag.
-
 Instead, the sponsee should include the
 git commit id of their HEAD
 in their handover email.
@@ -197,12 +195,6 @@ Check the git commit ID of the sponsee's branch tip,
 and the sha256sums of the .origs,
 against the handoff email.
 
-Confirm that the sponsee has not made
-a debian/1.2.3-1 tag.
-If they have,
-it is best to ask them to delete it now,
-as it can cause confusion later when dgit push produces its own tag.
-
 Now you can check out the branch tip,
 and do your substantive review.
 
@@ -228,7 +220,7 @@ C<dgit fetch sid> will get you an up-to-date
 C<refs/remotes/dgit/dgit/sid>
 showing what's in the archive already.
 
-C<dgit -wgf --damp-run push>
+C<dgit -wgf --damp-run push-source>
 will check that dgit can build an appropriate source package.
 
 There is no need to run debdiff.
@@ -242,17 +234,39 @@ When you have completed your source review,
 and use
 C<dgit -wgf [--quilt=...] sbuild -A -C>
 or similar, to to the build, and then
+C<dgit -wgf [--quilt=...] push-source>
+or
 C<dgit -wgf [--quilt=...] push>
 to do the upload.
 
-(If you switched to the quilt-cache dgit view,
-B<do not> pass the --quilt or --gbp or --dpm option again.)
+Check whether the sponsee made a debian/I<version> tag.
+If they did,
+ensure you have their tag in the repository you are pushing from,
+or pass C<--no-dep14tag>.
+This avoids identically named, non-identical tags,
+which can be confusing.
+
+(It is possible to upload from
+the quilt-cache dgit view.
+If you want to do this,
+B<do not> pass the C<--quilt> or C<--gbp> or C<--dpm> options again,
+and B<do> pass C<--no-dep14tag>,
+since the debian/I<version> tag
+should go on the sponsee's branch.)
 
 If this was the first upload done with dgit,
 you may need to pass
 C<--overwrite>
 to dgit.
 
+Alternatively,
+if this was the first ever dgit push of the package,
+you can pass C<--deliberately-not-fast-forward>
+instead of C<--overwrite>.
+This avoids introducing a new origin commit
+into the dgit view of
+the sponsee's git history
+which is unnecessary and could be confusing.
 
 =head1 SPONSORING A NON-GIT-USING SPONSEE
 
@@ -301,7 +315,7 @@ to dgit push for every successive upload.
 This disables a safety catch which would normally spot
 situations where changes are accidentally lost.
 When your sponsee is sending you source packages -
-perhaps multiple source pacakges with the same version number -
+perhaps multiple source packages with the same version number -
 these safety catches are inevitably ineffective.
 
 =head1 SEE ALSO