/ / /
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
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
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.)
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?
1 0 00 =XBC%
/
/
- --p--A breakwater
+ --@--A breakwater
/
--#--------> upstream
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
1 0 00 =XBC% /
/ /
/ /
- --p--A-----B--------------------p--C--D
+ --@--A-----B--------------------@--C--D
/ /
--#----------------------- - - / - - ----->
/