|author||Ian Jackson <firstname.lastname@example.org>||2016-10-30 23:31:28 +0000|
|committer||Ian Jackson <email@example.com>||2016-10-30 23:36:39 +0000|
dgit(1): Update BUGS section
Signed-off-by: Ian Jackson <firstname.lastname@example.org>
2 files changed, 14 insertions, 24 deletions
diff --git a/debian/changelog b/debian/changelog
index 1e856e6..a40d4d5 100644
@@ -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.
@@ -966,39 +966,28 @@ and other subprograms and modules used by dgit are affected by various
environment variables. Consult the documentaton for those programs
-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
+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