X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blobdiff_plain;f=dgit-sponsorship.7.pod;h=8d5b72daa2de1e42b11820c132cda72c260d3ce9;hp=8feb0d198657c53ece95685e80f8deef7beaeeaa;hb=c85ececfb4a825fe91cf45aa8ffae69863ace473;hpb=cb809d942c58dea5dfba6ad8b7e3298338ebb24e

diff --git a/dgit-sponsorship.7.pod b/dgit-sponsorship.7.pod
index 8feb0d19..8d5b72da 100644
--- a/dgit-sponsorship.7.pod
+++ b/dgit-sponsorship.7.pod
@@ -71,7 +71,10 @@ The git branch.
 
 =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 *
 
@@ -104,8 +107,6 @@ alioth 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.
@@ -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.
 
-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
 
@@ -138,7 +147,8 @@ or attach to the e-mail,
 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
 
@@ -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.
 
-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.
 
@@ -233,8 +237,20 @@ or similar, to to the build, and then
 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