talk.txt

diff --git a/talk.txt b/talk.txt
index abe3a534dbcbcce007a6f81a6be5fe2273fa90a0..0fb74adc5fecb3913fbad518c844b8630006c034 100644 (file)
--- a/talk.txt
+++ b/talk.txt
@@ -121,7 +121,9 @@ patches can also result in people having to read interdiffs, which are
 notoriously confusing.
 
 
-xxx plug plug
+So, in summary, if you are doing cross-archive work, or bug squashing,
+you can start using dgit right away and I hope it will make your life
+a lot easier.
 
 
 ==== NMU linear history on top of basic dgit history
@@ -218,27 +220,13 @@ dgit push imposes only two requirements on your git trees, which stem
 directly from dgit's objectives.
 
 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
-packaging branch without .pc directory'.  Patches-applied means that
-the upstream source files in the main package tree correspond to the
-actual source code that will be used when the package is built, rather
-than to the upstream versions.)
+the unpacked source package.
 
-xxx slide, longer explanation
-
-
-For all native packages, and for users of git-dpm and raw git, this is
+For all native and source format 1.0 packages (which will include
+people using raw git to manage their delta from upstream), this is
 already the interchange format.  These maintainers can start using
 dgit right away for all their maintainer uploads.  Please do!
 
-For those using git-buildpackage with `3.0 (quilt)', things are a bit
-more complicated.  I'm told that gbp pq can be used to generate a
-patches-applied branch, and that some users prefer to use that as the
-interchange git branch, but I know this is far from universal.  I'm
-talking to the git-buildpackage maintainers about gbp integration, so
-watch this space.  xxx
-
 The other requirement of dgit is simply that the dgit branches are
 fast-forwarding.  So if your tools have made a rebasing branch, you
 may need to make a fake merge (with git merge -s ours) before pushing.
@@ -246,6 +234,67 @@ I'm intending to provide some rather more cooked way to do this but I
 haven't decided the exact shape yet.
 
 
+==== 3.0 quilt applied slide
+
+For `3.0 (quilt)' packages, things are more complicated.  The purpose
+of dgit is to provide a git view which is identical to the source
+package, and can be worked on without knowledge of the maintainer's
+chosen source format, patch system or git workflow.
+
+This means that the dgit git tree for a `3.0 (quilt)' package is what
+is sometimes called a `patches-applied packaging branch without .pc
+directory'.
+
+This means that all the changes made in Debian are represented in the
+main source tree, as well as being contained within a patch in
+debian/patches.
+
+But: I think the most popular tool for working with `3.0 (quilt)' is
+git-buildpackage, and git-buildpackage likes to work with
+patches-unapplied tress.  I've spoken to Guido Guenther (the
+git-buildpackage maintainer) about this.  We had a really good
+conversation.  We have a plan for interoperating, which involves dgit
+synthesising an extra git commit, to apply the patches, and then
+pushing that to the dgit git server.  (The extra git commit wouldn't
+appear on your own branch; if it did, it would cause trouble.)
+
+=== xxxx status table
+
+There is another problem which affects both git-buildpackage and
+git-dpm: namely, .gitignore files.  Neither git-buildpackage nor
+git-dpm represent the .gitignore, which typically occurs in the git
+tree, as a patch in debian/patches.  Rather, these tools tell
+dpkg-source to ignore it when buildinng the source package.  So the
+source package does not contain .gitignore, although the git tree
+does.
+
+I have spoken to Bernhard Link (the git-dpm maintainer) about this and
+he wasn't keen on having git-dpm treat .gitignore normally, and record
+.gitignores in a patch in the git-dpm branch.  So unless we can
+persuade Bernhard to offer this, at least as an option, dgit is
+probably going to have to synthesise a commit to add them, in much the
+same way as it will add a commit to convert a git-buildpackage
+patches-unapplied branch to a directly-editable patches-applied one.
+
+
+
+xxx empty directories
+
+
+  I'm told that gbp pq can be used to generate a
+patches-applied branch, and that some users prefer to use that as the
+interchange git branch, but I know this is far from universal.  I'm
+talking to the git-buildpackage maintainers about gbp integration, so
+watch this space.
+
+
+, and for users of git-dpm and
+
+(more or less) 
+  xxx
+
+
+
 ==== data flow slide
 
 There are a few other things I ought to cover, since they often come
@@ -414,9 +463,11 @@ be covered include how to incorporate changes made in an NMU into the
 tool's favoured history format, and how to upgrade a package to a new
 upstream version.
 
-The bug I mention there is my request against git-dpm for anew manpage
-covering these topics, since I think the moving parts for git-dpm to
-work with dgit are generally in place.
+I'm talking to the xxx
+
+The bug I mention there is my request against git-dpm for a new
+manpage covering these topics, since I think the moving parts for
+git-dpm to work with dgit are generally in place.
 
 And this leads on to the question of how to use git-buildpackage and
 dgit together.  As I say, I'm talking to the gbp maintainers.
@@ -441,7 +492,7 @@ I hear rumours that Ubuntu might grow a dgit git server and support
 dgit push.  Patches very welcome!
 
 
-==== Thanks and more info slide
+xxx==== Thanks and more info slide
 
 xxx thank dsa ftpmaster