Hi Ferenc,

On Sun, Aug 12, 2018 at 09:56:17AM +0200, Ferenc Wágner wrote:
> Lumin <cdlumin...@gmail.com> writes:
> > The problem is, if I maintain the two releases in parallel, the
> > dch would become a mess when moving the 1.0 release to sid.
> > dch will contain duplicated changelog entries (e.g. fixing
> > common problems found in both 0.7 and 1.0) and the timeline
> > is also screwed up.
> Do you know dpkg-mergechangelogs?  I think fixing common problems in the
> experimental branch and periodically merging it into the unstable branch
> would work out fairly well with its help.  Of course you'd still have to
> fix up the version number after the merge.

Thank you for this reminder!  I had forgotten to activate the merge
driver in .git/info/attributes in the repo of the one bpo I maintain
where a no-change bpo is not possible.

For anyone else reading this, the easy and convenient solution is at
the bottom of dpkg-mergechangelogs(1) <- and that's a manpage.  So
with gbp, you git merge the new debian tag, the mergechangelogs magic
occurs, then you 'dch --bpo', commit the changelog, and you're good to
go--unless new changes are required, of course!


Attachment: signature.asc
Description: PGP signature

Reply via email to