chiark / gitweb /
dgit clone: No longer create an "origin" remote
[dgit.git] / dgit-sponsorship.7.pod
index 8d5b72daa2de1e42b11820c132cda72c260d3ce9..2e6f82d95071c74cc55033b03a73f56a15111aae 100644 (file)
@@ -9,7 +9,7 @@ and
 a sponsoring DD (or DM)
 can collaborate and publish using git.
 
 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.)
 (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
 =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)>.
 
 
 For a straightforward NMU, consult L<dgit-nmu-simple(7)>.
 
@@ -102,7 +102,7 @@ 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;
 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 branch names used by the sponsee on their local machine,
 and on the server, do not matter.
@@ -220,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<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.
 will check that dgit can build an appropriate source package.
 
 There is no need to run debdiff.
@@ -234,6 +234,8 @@ When you have completed your source review,
 and use
 C<dgit -wgf [--quilt=...] sbuild -A -C>
 or similar, to to the build, and then
 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.
 
 C<dgit -wgf [--quilt=...] push>
 to do the upload.
 
@@ -257,6 +259,14 @@ you may need to pass
 C<--overwrite>
 to dgit.
 
 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
 
 
 =head1 SPONSORING A NON-GIT-USING SPONSEE
 
@@ -305,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 -
 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
 these safety catches are inevitably ineffective.
 
 =head1 SEE ALSO