wip

diff --git a/talk.txt b/talk.txt
index 65eb184ae8367af8af5c085d71febd2ae6d8ea17..2c2df66ad592dd4748c91db69eb5cb60f212abd5 100644 (file)
--- a/talk.txt
+++ b/talk.txt
@@ -31,9 +31,9 @@ users, and so on.  Maintainers, please be patient - I'll get to you.
 The point of dgit is that it lets everyone treat the archive as if it
 were a git repository.
 
-You can dgit clone any package, in any suite in the archive (so, for
-example, sid or experimental) and you will get a git tree which is
-exactly the same as dpkg-source -x.
+You can dgit clone any package, in any suite (so, for example, sid or
+experimental) and you will get a git tree which is exactly the same as
+dpkg-source -x.
 
 You can then work on the package in git, the way you would work in git
 with any other project.  In particular, you can:
@@ -70,8 +70,7 @@ than representing the package's actual history.
 
 
 Which brings me onto the other side of this talk: dgit for
-maintainers.
-
+maintainers:
 
 ==== history comparison slide
 
@@ -81,14 +80,14 @@ with, your own history.
 
 But it's in your own interests, too:
 
-If you use dgit, you will be able to directly merge and/or cherry-pick
-NMUs, patches proposed via pull-request emails, and so on: Because, in
-this case, the dgit-using contributor will have based their work on
-your own history.
+If you use dgit, you will be able to directly merge NMUs, patches
+proposed via pull-request emails, and so on: Because, in this case,
+the dgit-using contributor will have based their work on your own
+history.
 
 Using dgit for your maintainer uploads will put your own history on
-browse.dgit.debian.org, rather than showing dgit's stub history (which
-can also be out of date).
+browse.dgit.debian.org, rather than advertising dgit's stub history
+(which can also be out of date).
 
 If you use dgit push, you get an extra check that the source package
 you are uploading is exactly the same as your git HEAD.  This can
@@ -101,17 +100,16 @@ And, as I say, non-maintainer dgit users will thank you.
 
 dgit is not a replacement for existing git packaging tools; it's
 intended to complement them.  So (unlike git-dpm) dgit does not define
-a git history structure, and (unlike git-buildpackage) it does not
-define a branch structure.  Nor does it require a particular source
-format.
+a git history structure; nor does it define a branch structure or
+require a particular source format.
 
 
-dgit push imposes only two requirements on your git trees.  These stem
-directly from dgit's design goals.
+dgit push imposes only two requirements on your git trees, which stem
+directly from dgit's goals.
 
 The most important requirement is that your git tree is identical to
 the unpacked source package.  (Technically, in the case of a `3.0
-(quilt)' package, it is what is sometimes called a `patches applied
+(quilt)' package, it is what is sometimes called a `patches-applied
 packaging branch without .pc'.)
 
 For all native packages, and for users of git-dpm and raw git, this is
@@ -139,13 +137,13 @@ There are a few other things I ought to cover, since they often come
 up.  They're are relevant to maintainers and non-maintainers:
 
 
-DMs currently need to email a signed copy of their ssh key, in order
-to be able to push.
+DMs currently need to email me a signed copy of their ssh key, in
+order to be able to push.
 
 
 The dgit view does not generally include the package upload history.
 git-import-dscs can produce a git branch representing the upload
-history, but dgit does do that itself.
+history, but dgit doesn't run that itself.
 
 One could push such a branch to the archive with dgit push.  But, it
 seems to me that the git history structure ought to up to the
@@ -166,14 +164,14 @@ around this: you can tell dgit to use git clean instead, avoiding the
 package's clean target entirely.
 
 
-Some maintainers' source packages contain files not in their git
-branches: most commonly, autotools output.  This is not compatible
-with dgit's purpose of providing a git view of the archive.
+Some source packages contain files not in the maintainers' git
+branches, and which are needed to build: most commonly, autotools
+output.  Such git branches are not useable with dgit.
 
 But nowadays most people recommend that the package build should
-always rerun autotools, anyway.  If you do that, then neither your git
-tree nor your source package need contain the autotools output and all
-is well.
+always rerun autotools.  If you do that, then neither your git tree
+nor your source package need contain the autotools output and all is
+well.
 
 Alternatively, you can commit the autotools output to git.