wip

diff --git a/notes b/notes
index 4e62252fa9e95259ece3eda5f2ca2c6ce75d089a..48b1759331c596374e13f5c3750d996f6617dbe9 100644 (file)
--- 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 :-/