git-debrebase: convert-from-gbp: Check separately for $dtag

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

diff --git a/dgit-sponsorship.7.pod b/dgit-sponsorship.7.pod
index 8feb0d198657c53ece95685e80f8deef7beaeeaa..3fbdac8651f7e15db0499740d3db1aad0aadeeed 100644 (file)
--- a/dgit-sponsorship.7.pod
+++ b/dgit-sponsorship.7.pod
@@ -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)>.
 


@@ -71,7 +71,10 @@ The git branch.
 
 =item *
 
 
 =item *
 

-Any .orig tarballs which will be needed.
+Any .orig tarballs which will be needed,
+or sample git-archive(1)
+or gbp-buildpackage(1)
+command(s) to generate them.

 
 =item *
 
 
 =item *
 


@@ -99,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;
 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.
 

-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.
 Instead, the sponsee should include the
 git commit id of their HEAD
 in their handover email.


@@ -119,8 +120,16 @@ in their handover email.
 If there are any .origs that are not in the archive already,
 the sponsor will need them as part of the upload.
 
 If there are any .origs that are not in the archive already,
 the sponsor will need them as part of the upload.
 

-The simplest approach is to
-commit them with pristine-tar(1), e.g.
+If the sponsee generated these tarballs with git-archive(1)
+or gbp-buildpackage(1),
+they can simply include a sample invocation of git-archive(1)
+or ensure that a suitable gbp.conf is present
+in the source package
+to generate the tarball.
+
+Otherwise, the simplest approach is to
+commit the orig tarballs
+with pristine-tar(1), e.g.

 
 =over 4
 
 
 =over 4
 


@@ -138,7 +147,8 @@ or attach to the e-mail,
 if they are small.
 
 The sponsee should quote sha256sums of the .origs in their
 if they are small.
 
 The sponsee should quote sha256sums of the .origs in their

-handoff email.
+handoff email,
+unless they supplied commands to generate them.

 
 =back
 
 
 =back
 


@@ -185,12 +195,6 @@ Check the git commit ID of the sponsee's branch tip,
 and the sha256sums of the .origs,
 against the handoff email.
 
 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.
 
 Now you can check out the branch tip,
 and do your substantive review.
 


@@ -216,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.


@@ -230,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
 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.
 

-(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.
 
 
 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
 
 
 =head1 SPONSORING A NON-GIT-USING SPONSEE