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