dgit-maint-debrebase(7): patch queue -> delta queue

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

diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod
index 3c454e08478d77d2178f1b943d826fcea75c1f56..f46944fe53cb646ef3b68a059e0f1ea23884b5f5 100644 (file)
--- a/dgit-maint-debrebase.7.pod
+++ b/dgit-maint-debrebase.7.pod
@@ -17,13 +17,19 @@ Some advantages of this workflow:
 
 =item
 
-Manipulate the patch queue using the full power of git-rebase(1),
+Manipulate the delta queue using the full power of git-rebase(1),
 instead of relying on quilt(1), and without having to switch back and
 forth between patches-applied and patches-unapplied branches when
 committing changes and trying to build, as with gbp-pq(1).
 
 =item
 
+If you are using 3.0 (quilt), provide your delta queue as a properly
+separated series of quilt patches in the source package that you
+upload to the archive (unlike with dgit-maint-merge(7)).
+
+=item
+
 Avoid the git tree being dirtied by the application or unapplication
 of patches, as they are always applied.
 
@@ -88,11 +94,11 @@ something like this:
 
 Now go ahead and Debianise your package.  Just make commits on the
 master branch, adding things in the I<debian/> directory.  If you need
-to patch the upstream source, see "EDITING THE PATCH QUEUE", below.
+to patch the upstream source, see "EDITING THE DELTA QUEUE", below.
 Note that there is no need to maintain a separate 'upstream' branch,
 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).
+work with upstream tags rather than any branches, except temporary
+branches used to prepare patches for forwarding upstream, for example.
 
 Finally, you need an orig tarball:
 
@@ -332,7 +338,7 @@ a tarball:
 
 =back
 
-=head1 EDITING THE PATCH QUEUE
+=head1 EDITING THE DELTA QUEUE
 
 =head2 Adding new patches
 
@@ -373,7 +379,7 @@ using git-rebase(1).  For example,
 =back
 
 If you take this approach, you should be very careful not to start the
-rebase earlier than the beginning of the patch queue.
+rebase earlier than the beginning of the delta queue.
 
 =head2 Editing patches: finishing a debrebase
 
@@ -395,12 +401,12 @@ git remote such as B<salsa.debian.org>,
 
 Note that each time you stitch a debrebase you introduce a pseudomerge
 into your git history, which may make it harder to read.  Try to do
-all of the editing of the patch queue that you think will be needed
+all of the editing of the delta queue that you think will be needed
 for this upload in a single debrebase, so that there is a single
 debrebase stitch.
 
 A strategy is to debrebase only right before you upload.  Before that
-point, instead of editing the existing patch series, you append fixup
+point, instead of editing the existing delta queue, you append fixup
 commits (and reversions of commits) that alter the upstream source to
 the required state.  You can freely push and pull from
 B<salsa.debian.org> during this.  Just before uploading, you debrebase
@@ -428,10 +434,10 @@ If you want to skip dgit's checks while iterating on a problem with
 the package build (for example, you don't want to commit your changes
 to git), you can just run dpkg-buildpackage(1) or debuild(1) instead.
 
-=head2 Laundering the patch queue before uploading
+=head2 Laundering the delta queue before uploading
 
 Just before you B<dgit push> or B<dgit push-source>, you might want to
-have git-debrebase(1) shuffle your branch such that the Debian patch
+have git-debrebase(1) shuffle your branch such that the Debian delta
 queue appears at the end:
 
 =over 4
@@ -490,7 +496,7 @@ probably want to debrebase before your next upload to tidy those up.
 
 For example, the NMUer might have used git-revert(1) to unapply one of
 your patches.  A debrebase will strip both the patch and the reversion
-from the patch series.
+from the delta queue.
 
 =head1 SEE ALSO