dgit(1): Update BUGS section

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

diff --git a/debian/changelog b/debian/changelog
index 1e856e690092059fb29f22ce61149f9e6b09ca29..a40d4d5463c9ec9a897a1cb4a66df55810ecb336 100644 (file)
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,7 @@ dgit (2.9~) unstable; urgency=low
     improved by Sean Whitton.
   * dgit(7): Substantial updates, including documenting split view.
   * dgit(1): Better cross-references.
+  * dgit(1): Improved BUGS section.
 
  --
 

diff --git a/dgit.1 b/dgit.1
index 90f9c10d9b642246c1e936f84998dda692f5f963..98b525bca0809ae5472822a7a7130def9bac4b80 100644 (file)
--- a/dgit.1
+++ b/dgit.1
@@ -966,39 +966,28 @@ and other subprograms and modules used by dgit are affected by various
 environment variables.  Consult the documentaton for those programs
 for details.
 .SH BUGS
-dgit's git representation of format `3.0 (quilt)' source packages does
-not represent the patch stack as git commits.  Currently the patch
-series representation cannot round trip between git and the archive.
-Ideally dgit would represent a quilty package with an origin commit of
-some kind followed by the patch stack as a series of commits followed
-by a pseudo-merge (to make the branch fast-forwarding).  This would
-also mean a new `dgit rebase-prep' command or some such to turn such a
-fast-forwarding branch back into a rebasing patch stack, and a `force'
-option to dgit push (perhaps enabled automatically by a note left by
-rebase-prep) which will make the required pseudo-merge.
-
-If the dgit push fails halfway through, it should be restartable and
-idempotent.  However this is not true for the git tag operation.
-Also, it would be good to check that the proposed signing key is
+There should be
+a `dgit rebase-prep' command or some such to turn a
+fast-forwarding branch containing pseudo-merges
+back into a rebasing patch stack.
+It might have to leave a note
+for a future dgit push.
+
+If the dgit push fails halfway through,
+it is not necessarily restartable and
+idempotent.
+It would be good to check that the proposed signing key is
 available before starting work.
 
-dgit's handling of .orig.tar.gz is not very sophisticated.  Ideally
-the .orig.tar.gz could be transported via the git repo as git tags.
-Doing this is made more complicated by the possibility of a `3.0
-(quilt)' package with multiple .orig tarballs.
-
-dgit's build functions, and dgit push, should not make any changes to
+dgit's build functions, and dgit push, may make changes to
 your current HEAD.  Sadly this is necessary for packages in the `3.0
 (quilt)' source format.  This is ultimately due to what I consider
 design problems in quilt and dpkg-source.
 
-There should be an option which arranges for the `3.0 (quilt)'
-autocommit(s) to not appear on your HEAD, but instead only in the
-remote tracking suite branch.
-
 --dry-run does not always work properly, as not doing some of the git
 fetches may result in subsequent actions being different.  Doing a
 non-dry-run dgit fetch first will help.
+--damp-run is likely to work much better.
 .SH SEE ALSO
 \fBdgit\fP(7),
 \fBdgit-*\fP(7),