X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blobdiff_plain;f=dgit-sponsorship.7.pod;h=3fc59d2f3ba5798a460ab6216f1cbe91465000fc;hp=3b8c3a8b3ad54a42e09a0150bae9f22be921052a;hb=127632098e58021e467fb56fa36466785f2cbe55;hpb=5439ecadb25350a6a5a63097fcaeabaf656128e6

diff --git a/dgit-sponsorship.7.pod b/dgit-sponsorship.7.pod
index 3b8c3a8b..3fc59d2f 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 *
 
@@ -119,8 +122,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 +149,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
 
@@ -178,12 +190,19 @@ Use C<git fetch> or C<git clone> to obtain the git branch
 prepared by your sponsee,
 and obtain any .origs mentioned by the sponsee
 (to extract .origs committed with pristine-tar,
-you can use origtargz(1).)
+you can use origtargz(1),
+or use "gbp clone --pristine-tar".)
 
 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.
 
@@ -195,9 +214,8 @@ you can convert their tree into the standard dgit view:
 
 =over 4
 
-    % dgit -wgf quilt-fixup
-    [ Watch for a message about split brain, and if so: ]
-    % git checkout -b dgit-view-for-review refs/dgit-intern/quilt-cache
+    % dgit -wgf --quilt=foo --dgit-view-save=unquilted quilt-fixup
+    % git checkout unquilted
 
 =back
 
@@ -227,7 +245,15 @@ 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,
+(It is possible to upload from
+the quilt-cache dgit view,
+but this will cause the debian/1.2.3-1 tag to be
+placed on this branch
+rather than the sponsee's working branch.
+Since this might be confusing,
+it is a good idea to switch back to the sponsee's view,
+after reviewing and before pushing.
+If you do want to upload from the quilt-cache dgit view,
 B<do not> pass the --quilt or --gbp or --dpm option again.)
 
 If this was the first upload done with dgit,
@@ -258,6 +284,17 @@ Then:
 
 =back
 
+Or for an entirely new package:
+
+=over 4
+
+    % mkdir PACKAGE
+    % cd PACKAGE
+    % git init
+    % dgit -pPACKAGE import-dsc /path/to/sponsee's.dsc +sponsee
+
+=back
+
 This will leave you looking at the sponsee's package,
 formatted as a dgit branch.