Hello,
On Sun 06 Jan 2019 at 01:07pm GMT, Ian Jackson wrote:
> Sean Whitton writes ("Re: Bug#857490: dgit: shouldn't fail when previous
> backport not mentioned in changelog"):
>> Suggesting that the user use --overwrite=2.13.0-1.1~bpo8+1, or `git
>> merge -s ours
Sean Whitton writes ("Re: Bug#857490: dgit: shouldn't fail when previous
backport not mentioned in changelog"):
> Suggesting that the user use --overwrite=2.13.0-1.1~bpo8+1, or `git
> merge -s ours dgit/dgit/stretch-backports`, is indeed what we should do.
>
> I think t
control: tag -1 -moreinfo
Hello,
On Sat 05 Jan 2019 at 07:14pm GMT, Ian Jackson wrote:
> Stepping back a bit: with a rebasing workflow such as you describe,
> dgit's sanity check strategy for overwriting-pseudomerges (which are
> basically like force pushes) cannot work.
>
> I am not sure if
Ian Jackson writes ("Re: Bug#857490: dgit: shouldn't fail when previous
backport not mentioned in changelog"):
> Does that make some kind of sense ? How can we better guide the user
> who finds themselves in this situation ?
#913451 "dgit manpages: discuss --overwrite in m
Control: tags -1 moreinfo
Sean Whitton writes ("Bug#857490: dgit: shouldn't fail when previous backport
not mentioned in changelog"):
> There are merge and rebase workflows in use for the Debian changelogs of
> backports. Some backport maintainers merge the new ve
Package: dgit
Version: 4.0
Severity: normal
There are merge and rebase workflows in use for the Debian changelogs of
backports. Some backport maintainers merge the new version in testing
into their backports branch, so that the previous backport's entry
remains in the changelog (the 'merge'
6 matches
Mail list logo
