From: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Sun, 24 Aug 2014 21:31:14 +0000 (+0100)
Subject: wip
X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ijackson/git?a=commitdiff_plain;h=68a92890fa339daff7e549f295f653699048ed65;p=talk-2014-debconf-dgit.git

wip
---

diff --git a/notes b/notes
index 4e62252..48b1759 100644
--- a/notes
+++ b/notes
@@ -1,4 +1,5 @@
--- PITCH --
+
+(PITCH)
 
 [archive as vcs]
 
@@ -55,7 +56,7 @@ have the full upstream git history in the ancestry if your dgit git
 history.
 
 
--- PRINCIPLES OF OPERATION --
+(PRINCIPLES OF OPERATION)
 
 [ .dsc, dpkg-source -x, git checkout, identity ]
 
@@ -77,29 +78,39 @@ current state of that package in the archive.
 
 [ synthetic commit example ]
 
-Non-dgit uploads do not contain a (suitable) git commit hash.  But
+Non-dgit uploads don't have a (suitable) git commit hash.  But
 dgit clone needs to produce a suitable git commit.  It does this by
 inventing (in a deterministic way) a commit corresponding to the state
 of the archive.  If necessary, it also generates a synthetic merge
 commit to tie the invented commit into the previous dgit history.
 
+(QUILTY WORKFLOW)
+
+At the moment, dgit doesn't attempt to do anything clever with `3.0
+(quilt)' source packages.
 
+The synthetic git history generated from non-dgit uploads does not
+represent the quilt patch stack.  And conversely, dgit push involves
+dpkg-source commit, to make the git tree be the same as dpkg-source
+would extract.  So dgit has to make some patches, and currently it
+makes single synthetic patch whose description contains some info from
+git log.
 
-    user has done build already (need for this may go away with
-      source-only uploads)
+Overall this means that currently when you work on a quilty package in
+dgit, you don't interact with the quilt patch stack.  This is less
+than ideal and I intend to improve this, perhaps by having dgit use
+git-dpm as a bidirectional gateway between `3.0 (quilt)' and git.
 
-    1. if `3.0 (quilt)', dpkg-source commit
-    2. fetch and check for ff-ness
-    3. check .dsc from build corresponds to git tree
-    4. insert git commit hash into .dsc, sign everything,
-       git push, dput
+This will generate a rebasing-style git branch.  After a patch series
+has been edited with rebase, dgit push will have to generate a `fake
+merge' commit to make the resulting history fast-forwarding.  (This is
+a well-understood git manipulation.)
 
-QUILTY WORKFLOW
+(ACCESS PROBLEMS)
 
-NON-FAST-FORWARDING ( not well support
+[table]
 
 
-ACCESS PROBLEMS
 
   works well for DDs
   works badly for everyone else :-/