-git-dpm sort of does this. I have been experimenting with and
-blundering towards another approach, which is closer to raw git.
-
-Something like this:
-
- ------/--A-----/---B3---/--> interchange view
- / / /
- / / 3
- / / /
- 2 2 2
- / / /
- 1 1 1
- / / /
- ---p-----p--A----p---B---> `packaging-only' branch
- / / /
- --#-----#-------#-----> upstream
-
- Key: 1,2,3 commits touching upstream files
- A,B commits touching debian/ only
- B3 mixed commit (eg made by an NMUer)
- # upstream releases
-
- -p- special merge, takes contents of debian/
- / from the previous `packaging only'
- commit and rest from upstream
-
- -/- pseudomerge; contents are identical to
- / parent lower on diagram.
-
-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.
-
-So it would be possible to write a `git-debian-rebase' tool which
-would take (for example) B3, 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 make
- a note, in your .git/ somewhere, of the latest pseudomerge to be
- deleted.)
-
- * 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.
-
- * New upstream rebase: Start rebasing onto a new upstream version,
- turning ...#...p-A-B-1-2 into ...#'...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.
-
- Note that the rebasing of p into p' cannot fail because p' 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.)
-
- * Record pseudomerge. This is like "committing" your patch queue.
- The LH parent is taken from the previous strip pseudomerge. (We
- should probably check that this is consistent with what we see in
- debian/changelog, but that is not a sufficient check.)
-
-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.)
-
-Ian.
-
---
-Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
-
-If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
-a private address which bypasses my fierce spamfilter.
-
-From: Ian Jackson <ijackson@chiark.greenend.org.uk>
-To: Sean Whitton <spwhitton@spwhitton.name>
-Cc: debian-devel@lists.debian.org
-Subject: Re: Feedback on 3.0 source format problems
-Date: Fri, 6 Jan 2017 15:29:38 +0000
-
-Sean Whitton writes ("Re: Feedback on 3.0 source format problems"):
-> Could you explain in general terms the difference between the
-> interchange and packaging-only branches
-
-See modified diagram below. Are the annotations I have added (and the
-name change) any help ?
-
-> Does the packaging-only branch contain debian/ alone?
-
-No, it also contains a complete unmodified copy of the upstream code.
-(Except that if upstream had a debian/ directory, it is completely
-replaced.) Perhaps this is the wrong name. Let's try
-`merging-baseline'
-
-For `3.0 (quilt)' the merging-baseline branch contains roughly what
-you would get if you untarred the origs and the debian.tar.gz, and
-then deleted all the patches without applying them.
-
-Not shown on the diagram is the commit `add patch queue to
-debian/patches', which would be needed for `3.0 (quilt)'. This is
-because the diagram is in terms of a sane source format, not `3.0
-(quilt)'. For use with quilty sources, there would be such a commit
-(probably dgit-generated) on top of the actual upstream change
-commits:
-