Hi Ferenc,
On Sun, Aug 12, 2018 at 09:56:17AM +0200, Ferenc Wágner wrote:
> Lumin 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!
Cheers,
Nicholas
signature.asc
Description: PGP signature
