From 3f7a40a0ecc3f792137cbaea07f085aa5f24dd4d Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Mon, 25 Aug 2014 01:46:48 +0100 Subject: [PATCH] wip --- notes | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/notes b/notes index cb873b5..ae076ff 100644 --- 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 -- 2.30.2