dgit: Option parsing: Fix undefined $suite in some import-dsc.

[dgit.git] / dgit-maint-merge.7.pod

diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod
index 5867a6b3ab681f7bed23a756fafef987192ab1ba..0d8b2daa9a37b3813bef116d67a8626f4c22e750 100644 (file)
--- a/dgit-maint-merge.7.pod
+++ b/dgit-maint-merge.7.pod
@@ -34,20 +34,6 @@ that upstream makes available for download.
 
 =back
 
-=head1 GIT CONFIGURATION
-
-Add the following to your ~/.gitconfig to teach git-archive(1) how to
-compress orig tarballs:
-
-=over 4
-
-    [tar "tar.xz"]
-       command = xz -c
-    [tar "tar.gz"]
-       command = gzip -c
-
-=back
-
 =head1 INITIAL DEBIANISATION
 
 This section explains how to start using this workflow with a new
@@ -94,16 +80,15 @@ unless you also happen to be involved in upstream development.  We
 work with upstream tags rather than any branches, except when
 forwarding patches (see FORWARDING PATCHES UPSTREAM, below).
 
-Finally, you need an orig tarball.  Generate one with git-archive(1):
+Finally, you need an orig tarball:
 
 =over 4
 
-    % git archive -o ../foo_1.2.2.orig.tar.xz 1.2.2
+    % git deborig
 
 =back
 
-If you are using the version 1.0 source package format, replace 'xz'
-with 'gz'.
+See git-deborig(1) if this fails.
 
 This tarball is ephemeral and easily regenerated, so we don't commit
 it anywhere (e.g. with tools like pristine-tar(1)).
@@ -121,7 +106,7 @@ A convenient way to perform this check is to import the tarball as
 described in the following section, using a different value for
 'upstream-tag', and then use git-diff(1) to compare the imported
 tarball to the release tag.  If they are the same, you can use
-upstream's tarball instead of running git-archive(1).
+upstream's tarball instead of running git-deborig(1).
 
 =back
 
@@ -187,6 +172,7 @@ this workflow.  It should be skipped when debianising a new package.
 
     % dgit clone foo
     % cd foo
+    % git remote add -f upstream https://some.upstream/foo.git
 
 =back
 
@@ -201,6 +187,14 @@ First, dump any existing patch queue:
 
 =back
 
+Then make new upstream tags available:
+
+=over 4
+
+    % git remote add -f upstream https://some.upstream/foo.git
+
+=back
+
 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.
@@ -209,6 +203,8 @@ To achieve this, you might need to delete
 I<debian/source/local-options>.  One way to have dgit check your
 progress is to run B<dgit build-source>.
 
+The first dgit push will require I<--overwrite>.
+
 =head1 SOURCE PACKAGE CONFIGURATION
 
 =head2 debian/source/options
@@ -227,7 +223,7 @@ source:
 You don't need to create this file if you are using the version 1.0
 source package format.
 
-=head2 Sample text for README.source
+=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
 changes to the upstream source:
@@ -252,6 +248,10 @@ See dgit(1), dgit(7) and dgit-maint-merge(7) for more information.
 
 =back
 
+Alternatively, this text could be added to README.source. However,
+this might distract from more important information present in the
+latter file.
+
 =head1 BUILDING AND UPLOADING
 
 Use B<dgit build>, B<dgit sbuild>, B<dgit build-source>, and B<dgit
@@ -298,18 +298,15 @@ Once you're satisfied with what will be merged, update your package:
 
 =over 4
 
-    % git archive -o ../foo_1.2.3.orig.tar.xz 1.2.3
     % git merge 1.2.3
     % dch -v1.2.3-1 New upstream release.
     % git add debian/changelog && git commit -m changelog
+    % git deborig
 
 =back
 
 and you are ready to try a build.
 
-Again, if you are using the version 1.0 source package format, replace
-'xz' with 'gz'.
-
 =head2 When upstream releases only tarballs
 
 You will need the I<debian/gbp.conf> from "When upstream releases only