dgit-maint-debrebase(7): correct what debrebase will do when debrebasing an NMU

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

diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod
index 599b6c7d406e35ad0c0d21564bc5c302f524c358..f5023e849ba5c6c271069e713a929bdf9c3974a4 100644 (file)
--- a/dgit-maint-debrebase.7.pod
+++ b/dgit-maint-debrebase.7.pod
@@ -488,8 +488,8 @@ If the NMUer added new commits modifying the upstream source, you will
 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 delta queue.
+your patches.  A debrebase can be used to strip both the patch and the
+reversion from the delta queue.
 
 =head2 Manually applying the debdiff
 
@@ -522,10 +522,8 @@ involved in upstream development).  We work with upstream tags rather
 than any branches, except temporary branches used to prepare patches
 for forwarding upstream, for example.
 
-The thought behind this is that branches are things to which one
-expects to commit, while tags are immutable points in history.  From
-the Debian point of the view, the upstream source is immutable.  It's
-our packaging to which we expect to commit.
+The thought behind this is that from Debian's point of view, upstream
+releases are immutable points in history, better represented by tags.
 
 =head2 The first ever dgit push
 
@@ -567,7 +565,7 @@ using git-rebase(1) directly.  For example,
 =back
 
 If you take this approach, you should be very careful not to start the
-rebase earlier than the beginning of the delta queue.
+rebase too early.
 
 =head1 SEE ALSO