wip

diff --git a/NOTES-2 b/NOTES-2
index 2add7d7f44166639c8202d6945d77a99c6ada81c..0961b96256b87506968503d28b532aedfadc8571 100644 (file)
--- a/NOTES-2
+++ b/NOTES-2
@@ -111,6 +111,8 @@ source-only one step push
 use of the dgit git repo server (other branches and tags) for general
 purpose work
 
+more assistance for use with raw git
+
 
 work needed
 

diff --git a/talk.txt b/talk.txt
index 43bebc32262d65e579a489b12ba6e291b90fa620..7a5fe89d91b84cf8e9a3402d6edd6674ab154c5d 100644 (file)
--- a/talk.txt
+++ b/talk.txt
@@ -1,6 +1,6 @@
 
 Hi.  I'm here to plug dgit, which is a tool (and infrastructure) for
-treating the Debian archive something like a git remote.
+treating the Debian archive like a git remote.
 
 I'm going to talk for about 35 minutess and then I'll take questions.
 
@@ -12,7 +12,8 @@ working on their own package, and everyone else.
 
 I'm going to start by presenting dgit from the point of view of
 everyone else: NMUers, sponsorship, teams doing cross-archive work
-(eg, transitions, reproducible builds), bug squashers, and so on.
+like transitions and reproducible builds, bug squashers, downstreams,
+users, and so on.
 
 
 The point of dgit is that it lets you treat the archive as if it were
@@ -23,38 +24,33 @@ 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:
+with any other project.  In particular, you can:
 
  * commit on your local branch
- * cherry pick
+ * cherry pick changes from other branches
  * git reset, git clean
- * git-rebase -i to polish your changes
+ * git rebase -i to polish a more complex set of changes into
+   a patch queue
 
 If you want so share your work-in-progress with others, you can git
-push the branch anywhere where they will be able to fetch it.
+push your branch anywhere where they will be able to fetch it.
 
-If you are a DD (or a DM for the package) you can also dgit push the
-package.  (Currently you still need to do a source package build.)
-
-
-Because dgit knows that your git tree is canonical, it can help you
-work around strangely behaved package clean targets: you can instruct
-dgit to use git clean rather than running the package's clean target.
+If you have the right authority you can also dgit push, to upload
+(after doing a build).
 
 
 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 use of particular
-source formats.
+define a branch structure.  Nor does it require a particular source
+format.
 
 
 The dgit history structure is up to the maintainer.  If you are doing
 a straightforward NMU you should produce a well-structured linear
-sequence of commits, the way that you would for any project which is
-using git upstream.  If the package is using a quilty source format,
-you should not touch debian/patches; dgit will take care of updating
-the quilt patch stack.
+sequence of commits, as you would for any git upstream.  If the
+package is using a quilty source format, you should not touch
+debian/patches; dgit will take care of updating the quilt patch stack.
 
 Unless the maintainer uses dgit, the history you see in dgit will not
 be the maintainer's history.  This is because maintainers' git
@@ -91,6 +87,8 @@ 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
 save you some dsc-based checks.
 
+And, of course, non-maintainer dgit users will thank you.
+
 
 dgit push imposes only two requirements on your git trees.  These stem
 directly from the need for the dgit view of package to be identical to
@@ -133,9 +131,9 @@ itself.
 
 There is nothing stopping anyone from pushing such a branch to the
 archive with dgit push.  But, it seems to me that the git history
-structure ought to up to the maintainer, and if the maintainer is
-choosing to use dgit, normally the maintainers's existing git history
-is more useful and interesting.
+structure ought to up to the maintainer, and if the maintainer chooses
+to use dgit, normally the maintainers's existing git history is more
+useful and interesting.
 
 
 When using dgit, it is normally best to use one of dgit's build
@@ -146,6 +144,12 @@ same, so if your git tree has .gitignore in it, your source package
 should too.
 
 
+Many packages have strangely-behaved or plain buggy clean targets.
+Because dgit knows that your git tree is canonical, it can help work
+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.  Because the point of dgit
 is to provide a git view of what's actually in the archive, this does
@@ -164,20 +168,6 @@ post-autotools git branch.
 
 
 
-
- cannot
-use such a git branch 
-
-people have different contents in their git branches to in their 
-
-
-
-To use dgit push, there are some things you may have to do
-differently.  
-
-
-
-
 The point, of course, of using