chiark / gitweb /
dgit-maint-merge(7): Restructure "NEW UPSTREAM RELEASES"
[dgit.git] / dgit-maint-merge.7.pod
index 47ac4a07143e75144dc9220615b4bdcfa4c0be46..ed7cdc060fac83be63547f2f9e60c605a8a13490 100644 (file)
@@ -40,10 +40,7 @@ This workflow is less suitable for some packages.
 When the Debian delta contains multiple pieces which interact,
 or which you aren't going to be able to upstream soon,
 it might be preferable to
-maintain the delta as a rebasing patch series,
-to facilitate
-reviewing/upstreaming/dropping
-individual pieces.
+maintain the delta as a rebasing patch series.
 For such a workflow see for example
 dgit-maint-gbp(7).
 
@@ -149,14 +146,28 @@ Now create I<debian/gbp.conf>:
     pristine-tar = False
     pristine-tar-commit = False
 
+    [import-orig]
+    merge-mode = merge
+
 =back
 
-Then we can import the upstream version:
+gbp-import-orig(1) requires a pre-existing upstream branch:
 
 =over 4
 
     % git add debian/gbp.conf && git commit -m "create gbp.conf"
-    % gbp import-orig ../foo_1.2.2.orig.tar.xz
+    % git checkout --orphan upstream
+    % git rm -rf .
+    % git commit --allow-empty -m "initial, empty branch for upstream source"
+    % git checkout -f master
+
+=back
+
+Then we can import the upstream version:
+
+=over 4
+
+    % gbp import-orig --merge-mode=replace ../foo_1.2.2.orig.tar.xz
 
 =back
 
@@ -208,9 +219,14 @@ Then make new upstream tags available:
 
 =back
 
+=for dgit-test dpkg-source-ignores begin
+
 Now you simply need to ensure that your git HEAD is dgit-compatible,
-i.e., it is exactly what you would get if you ran B<dpkg-buildpackage
--i\.git/ -I.git -S> and then unpacked the resultant source package.
+i.e., it is exactly what you would get if you ran
+B<dpkg-buildpackage -i'(?:^|/)\.git(?:/|$)' -I.git -S>
+and then unpacked the resultant source package.
+
+=for dgit-test dpkg-source-ignores end
 
 To achieve this, you might need to delete
 I<debian/source/local-options>.  One way to have dgit check your
@@ -238,16 +254,16 @@ source package format.
 
 =head2 Sample text for debian/source/patch-header
 
-It is a good idea to explain how a user can obtain a break down of the
+It is a good idea to explain how a user can obtain a breakdown of the
 changes to the upstream source:
 
 =over 4
 
 The Debian packaging of foo is maintained in git,
 using the merging workflow described in dgit-maint-merge(7).
-An automatically generated representation of the Debian changes follows.
+There isn't a patch queue that can be represented as a quilt series.
 
-A detailed break down of these changes is available from their
+A detailed breakdown of the changes is available from their
 canonical representation -
 git commits in the packaging repository.
 For example, to see the changes made by the Debian maintainer in the
@@ -255,15 +271,16 @@ first upload of upstream version 1.2.3, you could use:
 
 =over 4
 
-    % git clone https://git.dgit.debian.org/
+    % git clone https://git.dgit.debian.org/foo
     % cd foo
     % git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'
 
 =back
 
-See dgit-maint-merge(7) for more information.
-(If you have dgit, use dgit clone foo,
-rather than plain git clone.)
+(If you have dgit, use `dgit clone foo`,
+rather than plain `git clone`.)
+
+A single combined diff, containing all the changes, follows.
 
 =back
 
@@ -292,58 +309,74 @@ to git), you can just run dpkg-buildpackage(1) or debuild(1) instead.
 
 =head1 NEW UPSTREAM RELEASES
 
-=head2 When upstream tags releases in git
+=head2 Obtaining the release
 
-It's a good idea to preview the merge of the new upstream release.
-First, just check for any new or deleted files that may need
-accounting for in your copyright file:
+=head3 When upstream tags releases in git
 
 =over 4
 
     % git remote update
-    % git diff --stat master..1.2.3 -- . ':!debian'
 
 =back
 
-You can then review the full merge diff:
+=head3 When upstream releases only tarballs
+
+You will need the I<debian/gbp.conf> from "When upstream releases only
+tarballs", above.
+
+Then, either
 
 =over 4
 
-    % git merge-tree `git merge-base master 1.2.3` master 1.2.3 | $PAGER
+    % gbp import-orig --no-merge ../foo_1.2.3.orig.tar.xz
 
 =back
 
-Once you're satisfied with what will be merged, update your package:
+or if you have a working watch file
 
 =over 4
 
-    % git merge 1.2.3
-    % dch -v1.2.3-1 New upstream release.
-    % git add debian/changelog && git commit -m changelog
-    % git deborig
+    % gbp import-orig --no-merge --uscan
 
 =back
 
-and you are ready to try a build.
+=head2 Reviewing & merging the release
 
-=head2 When upstream releases only tarballs
+It's a good idea to preview the merge of the new upstream release.
+First, just check for any new or deleted files that may need
+accounting for in your copyright file:
 
-You will need the I<debian/gbp.conf> from "When upstream releases only
-tarballs", above.
+=over 4
 
-Then, either
+    % git diff --stat master..1.2.3 -- . ':!debian'
+
+=back
+
+You can then review the full merge diff:
 
 =over 4
 
-    % gbp import-orig ../foo_1.2.2.orig.tar.xz
+    % git merge-tree `git merge-base master 1.2.3` master 1.2.3 | $PAGER
 
 =back
 
-or if you have a working watch file
+Once you're satisfied with what will be merged, update your package:
+
+=over 4
+
+    % git merge 1.2.3
+    % dch -v1.2.3-1 New upstream release.
+    % git add debian/changelog && git commit -m changelog
+
+=back
+
+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
+a tarball:
 
 =over 4
 
-    % gbp import-orig --uscan
+    % git deborig
 
 =back