[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: divergence from upstream as a bug

Michael Banck <mbanck@debian.org> writes:

> On Mon, May 19, 2008 at 08:59:51AM +0200, Goswin von Brederlow wrote:
>> 2) feature branches
>> Each feature branche is based on upstream (with few exceptions) and
>> contains all changes for one feature.
>> Then you have an integration branche where all feature branches are
>> merged. The merging generally needs human interaction somewhere in the
>> history of the integration branch. Doesn't mean every merge needs it
>> though.
>> Unfortunately there seems to be no way to generate a patch series from
>> that other than one big patch for everything combined. The human
>> interaction stored in the integration branch can't be machine
>> transformed to make a patch series. It seems that that transformation
>> is just as difficult as the merge itself.
> The following might work:
> Try to git-format-patch (or whatever tool applies for the particular
> DVCS) each feature branch, see whether they apply cleanly by
> luck/accident.  If so, store them as a 3.0 (quilt) debian/patches.

They will not except for trivial cases. And in trivial cases you can
probably seperate patches from on big patch reasonably well too.

Anyway, if you do have such a case you can just claim you have a
stacked branches setup. Such a setup would have some file giving the
order in which branches should be applied and any order would do.

> If they do not apply cleanly, store them individually at
> debian/patch-series or some other directory to be agreed upon, and make
> patches.debian.org be aware of this, i.e. expose them similar to the
> debian/patches patches, but mark them as overlapping/conflicting.

Which might be usefull for upstream but not for anyone working on the
package to fix a bug. As such I don't think that has anything to do in
the source package. For feature branches I would rather have
patches.debian.org fetch the diff from the RCS directly or just link

> Another possibility would be to combine those feature branches which
> conflict which each other, but put the others in seperate patches, still
> using 3.0 (quilt); however, the combined patch of conflicting feature
> branches might be quite meaningless, so not sure about this.

I'm not sure if that is even worth it.


Reply to: