chiark / gitweb /
update
[talk-2015-debconf-dgit.git] / talk.txt
index c9e820cc21cae79b553e133f59bf7077f6d794d5..223503358ed6ec8c8340e361748538f1140e2846 100644 (file)
--- a/talk.txt
+++ b/talk.txt
@@ -91,6 +91,12 @@ for you.  If you /are/ doing a new upstream version, then presumably
 you have obtained the origs as part of preparing your package, or you
 can build them easily.
 
+I should mention that currently only dgit push updates the history on
+the dgit git server.  So until a package is pushed with dgit push for
+the first time, doesn't exist on that server; and even after then,
+non-dgit uploads are not recorded, so the history can be out of date.
+I'm hoping to improve this in the future.
+
 
 ==== NMU linear history slide
 
@@ -234,7 +240,7 @@ 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
+=== Status table 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
@@ -258,7 +264,6 @@ 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
@@ -278,23 +283,6 @@ 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
@@ -311,13 +299,11 @@ right now, have a record of DMs' ssh keys.
 
 The second thing that's less than ideal is that the dgit git history
 does not generally include the package upload history.
-git-import-dscs can produce a git branch representing the upload
-
-xxx patches-applied
-
-history, but dgit doesn't run that itself.  It would be difficult for
-dgit to do so because deciding which set of versions to include is
-nontrivial and of course it would involve an awful lot of downloading.
+git-import-dscs can produce a git branch more or less representing the
+upload history, but dgit doesn't run that itself.  It would be
+difficult for dgit to do so because deciding which set of versions to
+include is nontrivial and of course it would involve an awful lot of
+downloading.
 
 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