chiark / gitweb /
git-debrebase: docs etc.: Intend to recognise anchors by commit annotation
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Sun, 18 Feb 2018 11:45:57 +0000 (11:45 +0000)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Sat, 16 Jun 2018 15:06:58 +0000 (16:06 +0100)
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
NOTES.git-debrebase
README.git-debrebase

index b4ffdda..476120f 100644 (file)
@@ -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
index 01048ef..ba00951 100644 (file)
@@ -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?