In discussion on how to start using dgit when already using git, do not imply/assume...

[dgit.git] / dgit.1

diff --git a/dgit.1 b/dgit.1
index ebba8b656cb15939209a731589afc388d9d8f9e9..1204f4e16a0a6e930b0c7f475aed550e798e7ff5 100644 (file)
--- a/dgit.1
+++ b/dgit.1
@@ -278,7 +278,7 @@ This is like
 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

-.BR --clean=check " | " -wn
+.BR --clean=check " | " -wc

 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


@@ -342,7 +342,7 @@ as the Debian server will do this automatically when necessary.
 .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,

-fail.
+fail.  This is the default for Debian.

 .TP
 .BR --quilt=auto
 When fixing up source format `3.0 (quilt)' metadata, prefer to
 .TP
 .BR --quilt=auto
 When fixing up source format `3.0 (quilt)' metadata, prefer to


@@ -370,11 +370,11 @@ fixing up, dgit push will fail.
 .TP
 .BI -D
 Prints debugging information to stderr.  Repeating the option produces
 .TP
 .BI -D
 Prints debugging information to stderr.  Repeating the option produces

-more output (currently, up to -DD is meaningfully different).
+more output (currently, up to -DDD is meaningfully different).

 .TP
 .BI -c name = value
 .TP
 .BI -c name = value

-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.

 .TP
 .RI \fB-v\fR version "|\fB_\fR | " \fB--since-version=\fR version |\fB_\fR
 Specifies the
 .TP
 .RI \fB-v\fR version "|\fB_\fR | " \fB--since-version=\fR version |\fB_\fR
 Specifies the


@@ -478,9 +478,8 @@ will work when the suite is an unknown suite in the Debian archive.
 
 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.

 .TP
 .BI -C changesfile
 Specifies the .changes file which is to be uploaded.  By default
 .TP
 .BI -C changesfile
 Specifies the .changes file which is to be uploaded.  By default


@@ -500,7 +499,7 @@ default, in
 .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

-.BR .. ).
+.RB ( .. ).

 .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


@@ -531,12 +530,14 @@ It is always possible with dgit to clone or fetch a package, make
 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

-to construct the commit to push; the only requirement is that it is a
+to construct the commits to push;
+the only requirement is that what you push is a

 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.
 

-If you are using dgit to do an NMU, and don't know about the
+If you are using dgit to do an NMU (in Debian),
+and don't know about the

 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.


@@ -565,7 +566,7 @@ branch
 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

-be the same.  The resulting branch head can be merged into your
+be very similar.  The resulting branch head can be merged into your

 working branches
 .RB ( "git checkout master && git merge dgit/" \fIsuite\fR).
 
 working branches
 .RB ( "git checkout master && git merge dgit/" \fIsuite\fR).