chiark / gitweb /
git-debrebase: test suite: add some t-git-next-date
[dgit.git] / README.git-debrebase
index eed1754d3cf3b64484aa012b17c0bf02dd328a6b..ba00951dc8b2aae34ce39e1e1ed740ca8cd6ff30 100644 (file)
@@ -13,7 +13,7 @@ with a series of pseudomerges to make it fast-forwarding.
           /        /          /
          1        1          1    `breakwater' branch, merging baseline
         /        /          /     unmodified upstream code
-    ---p-----p--A----p--B--C      plus debian/ (but no debian/patches)
+    ---@-----@--A----@--B--C      plus debian/ (but no debian/patches)
       /     /       /                    no ref refers to this: we
    --#-----#-------#-----> upstream        reconstruct its identity by
                                           inspecting interchange branch
@@ -24,7 +24,7 @@ with a series of pseudomerges to make it fast-forwarding.
       B3      mixed commit (eg made by an NMUer)
       #       upstream releases
 
-     -p-      special merge, takes contents of debian/ from the
+     -@-      anchor merge, takes contents of debian/ from the
      /         previous `breakwater' commit and rest from upstream
 
      -/-      pseudomerge; contents are identical to
@@ -47,27 +47,29 @@ 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 `p' 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:
 
  * Strip pseudomerges: Rewrite the current branch so it contains no
-   pseudomerges, turning ...B3 into ...p-A-1-2-B3.  (This should
+   pseudomerges, turning ...B3 into ...@-A-1-2-B3.  (This should
    make a note, in your .git/ somewhere, of the original branch
    tip so that it can be overwritten with a pseudomerge.)
 
  * Cleanup branch: Reorganise the current branch so that the debian/
-   changes come first, turning -p-A-1-2-B3 into ...p-A-B-1-2-3.
+   changes come first, turning -@-A-1-2-B3 into ...@-A-B-1-2-3.
 
  * New upstream rebase: Start rebasing onto a new upstream version,
-   turning ...#..p-A-B-1-2-3 into (...#..p-A-B-|...#'-)p'-1-2.  This
-   would be a wrapper around git-rebase, which prepares p' and then
-   tries to rebase 1 2 onto p'.  So if you ask for an interactive
-   rebase p' doesn't appear in your commit list.
+   turning ...#..@-A-B-1-2-3 into (...#..@-A-B-|...#'-)@'-1-2.  This
+   would be a wrapper around git-rebase, which prepares @' and then
+   tries to rebase 1 2 onto @'.  So if you ask for an interactive
+   rebase @' doesn't appear in your commit list.
 
-   Note that the construction of p' cannot fail because p' simply
+   Note that the construction of @' cannot fail because @' simply
    copies debian/ from B and and everything else from #'.  (Rebasing A
    and B is undesirable.  We want the debian/ files to be non-rebasing
    so we can `git log' and get the packaging history.)
@@ -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 `p'.
-(Indeed I since upstream might copy debian/ from us, I think it is not
-easy to reliably distinguish the two parents of a `p'.  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?
@@ -120,7 +126,7 @@ Consider a non-dgit NMU followed by a dgit NMU:
                   1          0 00 =XBC%
                  /
                 /
-                 --p--A     breakwater
+                 --@--A     breakwater
           /
        --#--------> upstream
 
@@ -153,14 +159,14 @@ Want to transform this into:
                   1          0 00 =XBC%            /
                  /                                       /
                 /                                       /
-         --p--A-----B-----------------------C--D
+         --@--A-----B-----------------------C--D
           /
        --#----------------------------------------->
 
 
  II. New upstream (0 + 00 neq #)
 
-                        --/--B3!--%--/------E*-------------/-->
+                        --/--B3!--%--/------D*-------------/-->
                          /          /                    /
                         %          4                    4**
                        /          3                    3
@@ -171,7 +177,7 @@ Want to transform this into:
                   1          0 00 =XBC%            /
                  /                               /
                 /                               /
-         --p--A-----B--------------------p--C--D
+         --@--A-----B--------------------@--C--D
           /                             /
        --#----------------------- - -  /  - - ----->
                                       /