chiark / gitweb /
wip
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Mon, 25 Aug 2014 00:46:48 +0000 (01:46 +0100)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Mon, 25 Aug 2014 00:46:48 +0000 (01:46 +0100)
notes

diff --git a/notes b/notes
index cb873b5f6f23e67d81b0f21331bdf8f16781e03a..ae076ffd2a789c96290adc2462a27c1807fd6f73 100644 (file)
--- a/notes
+++ b/notes
@@ -103,12 +103,12 @@ dgit, you don't interact with the quilt patch stack.  This is less
 than ideal.
 
 I intend to improve this, perhaps by having dgit use git-dpm as a
-bidirectional gateway between `3.0 (quilt)' and git.
-
-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.)
+bidirectional gateway between `3.0 (quilt)' and git.  Exactly how to
+do this involves some complicated design decisions which I haven't
+entirely worked out yet.  The intent, though, is that there will be an
+option to generate a rebasing-style git branch.  After a patch series
+has been edited with rebase, dgit push will generate a `fake merge'
+commit to make the resulting history fast-forwarding.
 
 (ACCESS PROBLEMS)
 
@@ -118,8 +118,8 @@ Probably the biggest problem with dgit right now is that it is only
 useable for DDs.  This is particularly galling for a tool which is
 especially useful for users, downstreams, mentees, and so forth.
 
-There are two obstacles to widening the access, relating to the
-archive and to the git server.
+There are two obstacles to widening the access, one relating to the
+archive and one to the git server.
 
 Firstly, dgit needs to query the archive to find the current version
 of the package and obtain a copy of the .dsc.  At the moment there is