git-debrebase: docs etc.: Intend to recognise anchors by commit annotation

[dgit.git] / README.git-debrebase

diff --git a/README.git-debrebase b/README.git-debrebase
index 01048ef5ad5db895bfb0f203faef239638cb617f..ba00951dc8b2aae34ce39e1e1ed740ca8cd6ff30 100644 (file)
--- 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?