dgit (0.16~experimental2) experimental; urgency=low
* WIP remote functionality. Untested, do not use.
+ * push actually takes an optional suite, like it says in the synopsis.
--
check_not_dirty();
my $clogp = parsechangelog();
$package = getfield $clogp, 'Source';
+ my $specsuite;
if (@ARGV==0) {
- $isuite = getfield $clogp, 'Distribution';
- if ($new_package) {
- local ($package) = $existing_package; # this is a hack
- canonicalise_suite();
- }
+ } elsif (@ARGV==1) {
+ ($specsuite) = (@ARGV);
} else {
badusage "incorrect arguments to dgit push";
}
+ $isuite = getfield $clogp, 'Distribution';
+ if ($new_package) {
+ local ($package) = $existing_package; # this is a hack
+ canonicalise_suite();
+ }
+ if (defined $specsuite && $specsuite ne $isuite) {
+ canonicalise_suite();
+ $csuite eq $specsuite or
+ fail "dgit push: changelog specifies $isuite ($csuite)".
+ " but command line specifies $specsuite";
+ }
if (check_for_git()) {
git_fetch_us();
}
Tagging, signing and actually uploading should be left to dgit push.
.TP
-.B dgit push
+\fBdgit push\fR [\fIsuite\fP]
Does an `upload', pushing the current HEAD to the archive (as a source
package) and to dgit-repos (as git commits). The package must already
have been built ready for upload, with the .dsc and .changes
archive.
dgit push always uses the package, suite and version specified in the
-debian/changelog and the .dsc, which must agree.
+debian/changelog and the .dsc, which must agree. If the command line
+specifies a suite then that must match too.
If dgit push fails while uploading, it is fine to simply retry the
dput on the .changes file at your leisure.