Debian packaging with git and conflicts resolution

[Russ Allbery]

martin f krafft <madduck at debian.org> writes:
> also sprach Russ Allbery <rra at stanford.edu> [2008.11.19.0122 +0100]:

>> You load the new upstream into the upstream branch.  Now, you merge the
>> new upstream into the A, B, and C topic branches.  In each case,
>> upstream used a slightly different bug fix than you had in their new
>> release (different wording, different comments, different whitespace,
>> what have you).  So in each of the topic branches, you had to resolve
>> conflicts between the new upstream and your fix.
>
> If upstream has fixed the problems that had you use A,B,C in the
> first place, why merge them back into the integration branch? After
> you merged upstream there, A,B,C have been obsoleted, no?

That's a trivial special case but doesn't help in the general case where
some of the fixes in each those branches still apply.

> Anyway, I am starting to doubt the need for a long-lived integration
> branch. What are the benefits of that approach, as opposed to
> creating a new integration branch for each Debian release?

I think this is where Manoj's point comes in.  It helps when there are
conflicts between the branches.  With a long-lived integration branch, you
don't have to re-resolve those conflicts each time.  (Although  I suppose
you could just let git rerere handle that.)

For the workflow that I was describing, which assumes no interbranch
conflicts, there probably isn't a need.  I think it's kind of nice to
someone wanting to hack on the package to let them pull down the current
merged package source, but I also don't use TopGit yet, which may well
change how I think about this.

It's also not an issue if you resolve conflicts between branches by making
one branch depend on another, which in reading between the lines I think
is the approach you're taking (although I could be wrong).

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>