X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=dgit-maint-debrebase.7.pod;h=9c9598bb6570c52439cd14928be4983b6671c2d2;hb=e82d9492c0a63d75c96e2ebdbc93300d57927d60;hp=f167928a4b3e0e4a75a19d0134616f74cbbe3e1a;hpb=b7f48e640bca6c2542c206c9bb7cdab182ba0a2c;p=dgit.git diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod index f167928a..9c9598bb 100644 --- a/dgit-maint-debrebase.7.pod +++ b/dgit-maint-debrebase.7.pod @@ -134,6 +134,32 @@ using git-diff(1) to compare the imported tarball to the release tag. =back +=head3 Using untagged upstream commits + +=over 4 + +Sometimes upstream does not tag their releases, or you want to package +an unreleased git snapshot. In such a case you can create your own +upstream release tag, of the form BI, where I is +the upstream version you plan to put in I. The +B prefix ensures that your tag will not clash with any tags +upstream later creates. + +For example, suppose that the latest upstream release is 1.2.2 and you +want to package git commit ab34c21 which was made on 2013-12-11. A +common convention is to use the upstream version number +1.2.2+git20131211.ab34c21 and so you could use + +=over 4 + + % git tag -s upstream/1.2.2+git20131211.ab34c21 ab34c21 + +=back + +to obtain a release tag, and then proceed as above. + +=back + =head2 When upstream releases only tarballs Because we want to work in git, we need a virtual upstream branch with @@ -331,6 +357,10 @@ release, and importing that release using git-debrebase(1). =back +If you want to package an untagged upstream commit (because upstream +does not tag releases or because you want to package an upstream +development snapshot), see "Using untagged upstream commits" above. + =head3 When upstream releases only tarballs You will need the I from "When upstream releases only @@ -375,9 +405,10 @@ release: =back -Pass I<--stat> just to see the list of changed files, which is useful -to determine whether there are any new or deleted files to may need -accounting for in your copyright file. +Also, diff with I<--name-status> and I<--diff-filter=ADR> to see +just the list of added or removed files, which is useful to determine +whether there are any new or deleted files that may need accounting +for in your copyright file. If you obtained a tarball from upstream, you are ready to try a build. If you merged a git tag from upstream, you will first need to generate @@ -451,7 +482,7 @@ In some cases where you used B since the last upload, it is not possible for dgit to make your history fast-forwarding from the history on B. In such cases you will have to pass I<--overwrite> to dgit. git-debrebase will normally -tell you if this is will be needed. +tell you if this will be needed. Right before uploading, if you did not just already do so, you might want to have git-debrebase(1) shuffle your branch such that the Debian @@ -487,7 +518,9 @@ email your archive administrators. For Debian that is Our approach is to maintain a DFSG-clean upstream branch, and create tags on this branch for each release that we want to import. We then -import those tags per "Importing the release", above. +import those tags per "Importing the release", above. In the case of +a new package, we base our initial Debianisation on our first +DFSG-clean tag. For the first upstream release that requires DFSG filtering: @@ -498,11 +531,23 @@ For the first upstream release that requires DFSG filtering: % git commit -m "upstream version 1.2.3 DFSG-cleaned" % git tag -s 1.2.3+dfsg % git checkout master - % # proceed with "Importing the release" on 1.2.3+dfsg tag =back -And for subsequent releases (whether or not they require filtering): +Now either proceed with "Importing the release" on the 1.2.3+dfsg tag, +or in the case of a new package, + +=over 4 + + % git branch --unset-upstream + % git reset --hard 1.2.3+dfsg + +=back + +and proceed with "INITIAL DEBIANISATION". + +For subsequent releases (whether or not they require additional +filtering): =over 4 @@ -545,7 +590,7 @@ In the simplest case, =back -If that fails, because your branch and the NMUers work represent +If that fails, because your branch and the NMUers' work represent divergent branches of development, you have a number of options. Here we describe the two simplest.