summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorIan Jackson <ijackson@chiark.greenend.org.uk>2018-02-18 11:45:57 +0000
committerIan Jackson <ijackson@chiark.greenend.org.uk>2018-06-16 16:06:58 +0100
commit1f38f570ed4d2df5ba72596c36311f6ff61238be (patch)
treeba1dba6c2da27b5e8a34b3aaf69cbe68300ba605
parentad22a602e0a701c6527c94496d2aa7cd2e4ab1b6 (diff)
git-debrebase: docs etc.: Intend to recognise anchors by commit annotation
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
-rw-r--r--NOTES.git-debrebase2
-rw-r--r--README.git-debrebase26
2 files changed, 18 insertions, 10 deletions
diff --git a/NOTES.git-debrebase b/NOTES.git-debrebase
index b4ffdda..476120f 100644
--- a/NOTES.git-debrebase
+++ b/NOTES.git-debrebase
@@ -1,4 +1,6 @@
TODO
+ recognise anchor merge by annotation, not just by structure
+
reference docs
git-debrebase(5) data model
git-debrebase(1) command line
diff --git a/README.git-debrebase b/README.git-debrebase
index 01048ef..ba00951 100644
--- a/README.git-debrebase
+++ b/README.git-debrebase
@@ -47,8 +47,10 @@ with a series of pseudomerges to make it fast-forwarding.
Looking from the tip of the interchange view, it is I think always
possible to classify these commits appropriately: pseudomerges are
fairly obvious (if all three trees are identical, we descend to the
-parent with the most recent commit date), and the `@' special merge is
-the only non-pseudo merge and has a special form.
+parent with the most recent commit date). The `@' special merge is
+the only non-pseudo merge and has a special form; also, it will be
+generated only by our tools so can have an annotation in the commit
+message.
So it would be possible to write a `git-debrebase' tool which would
take (for example) B4, above, and be able to perform functions like:
@@ -81,14 +83,18 @@ take (for example) B4, above, and be able to perform functions like:
Maybe some of these operations should automatically edit
debian/changelog.
-The only thing that this can't easily do is permit nonlinear (ie,
-merging) history on the `packaging-only' branch, because upstream
-might contain debian/ files too, so it is not possible to distinguish
-a merge of two `packaging-only' branches from the special merge `@'.
-(Indeed I since upstream might copy debian/ from us, I think it is not
-easy to reliably distinguish the two parents of a `@'. In the most
-exciting edge case, upstream might `git merge' a previous instance of
-our interchange view, but I think even then everything still works.)
+Nonlinear (merging) history in the interchange branch is awkward
+because it (obviously) does not preserve the patch queue.
+
+Nonlinear (merging) history in the `packaging-only' branch is OK, if
+we could generate it. We will use the commit message annotation to
+distinguish a merge of two `packaging-only' branches from the special
+merge `@'. (Indeed I since upstream might copy debian/ from us,
+without the annotation and knowledge of the construction order it is
+not easy to reliably distinguish the two parents of a `@'. In the
+most exciting edge case, upstream might `git merge' a previous
+instance of our interchange view, but I think even then everything
+still works.)
Sean Whitton writes ("Re: Feedback on 3.0 source format problems"):
> Does the [breakwater] branch contain debian/ alone?