|author||Ian Jackson <email@example.com>||2018-06-27 18:22:35 +0100|
|committer||Ian Jackson <firstname.lastname@example.org>||2018-06-27 18:24:59 +0100|
dgit(1): Better description of --overwrite.
In particular, be clear that --overwrite (without previous-version) is quite a weak promise: that the version you are uploading contains everything in your changelog. It won't overwrite willy-nilly. Somewhat apropos of discussion in #902534. Signed-off-by: Ian Jackson <email@example.com>
Diffstat (limited to 'dgit.1')
1 files changed, 15 insertions, 7 deletions
@@ -514,11 +514,15 @@ push will still ensure that the .dsc you upload and the git tree
you push are identical, so this option won't make broken pushes.)
.BR --overwrite [=\fIprevious-version\fR]
-Declare that even though your git branch may not be a descendant
+Declare that your HEAD really does contain
+all the (wanted) changes
+from all versions listed in its changelog;
+or, all (wanted) changes from
+.IR previous-version .
+This promise is needed when
+your git branch is not a descendant
of the version in the archive
-according to the revision history,
-it really does contain
-all the (wanted) changes from that version.
+according to the git revision history.
This option is useful if you are the maintainer, and you have
incorporated NMU changes into your own git workflow in a way that
@@ -530,15 +534,19 @@ to a particular suite.
.BR dgit-maint- \fI*\fR (7) .
-ought to be the version currently in the archive. If
specified, dgit will check that the version in the archive is
mentioned in your debian/changelog.
(This will avoid losing
-changes unless someone committed to git a finalised changelog
+changes, even with
+.BR --overwrite ,
+unless someone committed to git a finalised changelog
entry, and then made later changes to that version.)
+is specified, it ought to be the version currently in the archive.
dgit push --overwrite
will, if necessary, make a