X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blobdiff_plain;f=dgit-sponsorship.7.pod;h=3fbdac8651f7e15db0499740d3db1aad0aadeeed;hp=2bc9454656ff7aa98039fbeb1775adc56a097f12;hb=85d9ed1859b0ca7d223f9d2d9077290d69617675;hpb=1468397432c47b2a779570991f228c81622bce81 diff --git a/dgit-sponsorship.7.pod b/dgit-sponsorship.7.pod index 2bc94546..3fbdac86 100644 --- 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 -to upload it with C yourself. +to upload it with C or C yourself. For a straightforward NMU, consult L. @@ -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 * @@ -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; -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 CI 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 @@ -196,9 +206,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 @@ -211,7 +220,7 @@ C will get you an up-to-date C showing what's in the archive already. -C +C will check that dgit can build an appropriate source package. There is no need to run debdiff. @@ -225,17 +234,39 @@ When you have completed your source review, and use C or similar, to to the build, and then +C +or C to do the upload. -(If you switched to the quilt-cache dgit view, -B pass the --quilt or --gbp or --dpm option again.) +Check whether the sponsee made a debian/I 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 pass the C<--quilt> or C<--gbp> or C<--dpm> options again, +and B pass C<--no-dep14tag>, +since the debian/I 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