will be passed on to dpkg-buildpackage. It is not necessary to use
dgit build when using dgit; it is OK to use any approach which ensures
that the generated source package corresponds to the relevant git
will be passed on to dpkg-buildpackage. It is not necessary to use
dgit build when using dgit; it is OK to use any approach which ensures
that the generated source package corresponds to the relevant git
but it also removes any subdirectories containing different git
trees (which only unusual packages are likely to create).
.TP
but it also removes any subdirectories containing different git
trees (which only unusual packages are likely to create).
.TP
Merely check that the tree is clean (does not contain uncommitted
files), before building a source package.
.TP
Merely check that the tree is clean (does not contain uncommitted
files), before building a source package.
.TP
.BR --quilt=linear
When fixing up source format `3.0 (quilt)' metadata, insist on
generating a linear patch stack. If such a stack cannot be generated,
.BR --quilt=linear
When fixing up source format `3.0 (quilt)' metadata, insist on
generating a linear patch stack. If such a stack cannot be generated,
-Specifies a git configuration option. dgit itself is also controlled
-by git configuration options.
+Specifies a git configuration option, to be used for this run.
+dgit itself is also controlled by git configuration options.
To define a new distro it is necessary to define methods and URLs
for fetching (and, for dgit push, altering) a variety of information both
To define a new distro it is necessary to define methods and URLs
for fetching (and, for dgit push, altering) a variety of information both
-in the archive and in dgit-repos. How to do this is not yet
-documented, and currently the arrangements are unpleasant. See
-BUGS.
+in the archive and in dgit-repos.
+How to set this up is not yet documented.
.BI --build-products-dir= directory
Specifies where to find the built files to be uploaded.
By default, dgit looks in the parent directory
.BI --build-products-dir= directory
Specifies where to find the built files to be uploaded.
By default, dgit looks in the parent directory
.TP
.BI --existing-package= package
dgit push needs to canonicalise the suite name. Sometimes, dgit
.TP
.BI --existing-package= package
dgit push needs to canonicalise the suite name. Sometimes, dgit
changes in git (using git-commit) on the suite branch
.RB ( "git checkout dgit/" \fIsuite\fR)
and then dgit push. You can use whatever gitish techniques you like
changes in git (using git-commit) on the suite branch
.RB ( "git checkout dgit/" \fIsuite\fR)
and then dgit push. You can use whatever gitish techniques you like
descendant of the state of the archive, as provided by dgit in the
remote tracking branch
.BR remotes/dgit/dgit/ \fIsuite\fR.
descendant of the state of the archive, as provided by dgit in the
remote tracking branch
.BR remotes/dgit/dgit/ \fIsuite\fR.
maintainers' preferred packaging workflows, you should make your
changes as a linear series of (logicially separated) commits on top of
what's already in the archive.
maintainers' preferred packaging workflows, you should make your
changes as a linear series of (logicially separated) commits on top of
what's already in the archive.
and merge that other commit
.RB ( "git merge debian/" \fIversion\fR).
Hopefully this merge will be trivial because the two trees should
and merge that other commit
.RB ( "git merge debian/" \fIversion\fR).
Hopefully this merge will be trivial because the two trees should
Specifies the distro for a suite. dgit keys off the suite name (which
appears in changelogs etc.), and uses that to determine the distro
which is involved. The config used is thereafter that for the distro.
Specifies the distro for a suite. dgit keys off the suite name (which
appears in changelogs etc.), and uses that to determine the distro
which is involved. The config used is thereafter that for the distro.