martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Russ Allbery <[EMAIL PROTECTED]> [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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
vcs-pkg-discuss mailing list