Simon McVittie <s...@debian.org> writes: > I think the bottom line here is that what you are doing *is* rebasing: > you are treating the new upstream (or new security-patched downstream) > as the new baseline for your local work, discarding any of your changes > that are no longer necessary, and adjusting the rest to apply on top of > the new version.
Sort of, but here's the tricky part: I want to rebase the upstream changes, but I want to merge the Debian changes, because merging usually works better there than rebasing. I also don't want this represented as a rebase because I'd like to git pull my new archive in various places without having to delete and recreate my branch. I agree that there's nothing special about patches for this, and you can do the whole thing with pure Git (and indeed that seems to basically be what git-dpm does: rebase the upstream patches and merge the packaging). I think the question of whether you do the rebasing via manipulating patches or via git rebase on a specially-created branch for that purpose is something of a matter of taste. I find fiddling with patches with the help of gbp pq to be more straightforward and comprehensible; other people will be more comfortable with git rebase -i and friends. The important part to me isn't so much the precise set of tools as it is that people not push me into merging when I want to rebase (because I think rebase is the better strategy), and that I can make available the rebased patches in some easily interchangeable form both upstream and downstream. Everyone understands patches, so patches are a really nice export format to achieve that latter goal. I don't have any technical support conversations about how to deal with the patches. In theory, a rebased Git branch should be equally accessible, and has some practical advantages, but I do still work with upstreams who use Subversion, and I *know* patches work. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>