From e1b329ed875a5d1cdd4666cf8dc66ae839324d9f Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Sun, 30 Oct 2016 23:31:28 +0000 Subject: [PATCH] dgit(1): Update BUGS section Signed-off-by: Ian Jackson --- debian/changelog | 1 + dgit.1 | 37 +++++++++++++------------------------ 2 files changed, 14 insertions(+), 24 deletions(-) diff --git a/debian/changelog b/debian/changelog index 1e856e69..a40d4d54 100644 --- 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 90f9c10d..98b525bc 100644 --- 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), -- 2.30.2