Re: Converting to dgit
Simon McVittie <smcv@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: