Path: csiph.com!feeder.erje.net!1.eu.feeder.erje.net!weretis.net!feeder4.news.weretis.net!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod From: Thomas Goirand Newsgroups: linux.debian.maint.python Subject: Re: git-dpm -> gbp conversion (mass-change) Date: Thu, 09 Aug 2018 10:20:01 +0200 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Thu Aug 9 08:16:51 2018 Old-Return-Path: X-Amavis-Spam-Status: No, score=-6.98 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, LDO_WHITELIST=-5, MURPHY_DRUGS_REL8=0.02, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -5 Organization: Debian User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Mailing-List: archive/latest/16198 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/4a75664f-b4d6-7eb0-f5fd-1974b20c53be@debian.org Approved: robomod@news.nic.it Lines: 31 Sender: robomod@news.nic.it X-Original-Date: Thu, 9 Aug 2018 10:16:31 +0200 X-Original-Message-ID: <4a75664f-b4d6-7eb0-f5fd-1974b20c53be@debian.org> X-Original-References: <20180802151614.jlu5w3l3lnhwi3he@werner.olasd.eu> <20180804070542.ehshncjtlx4lsswf@macbookair> <87h8k53x69.fsf@vostro.rath.org> <87eff84qf3.fsf@vostro.rath.org> Xref: csiph.com linux.debian.maint.python:10778 On 08/08/2018 09:19 PM, Nikolaus Rath wrote: > On Aug 08 2018, Thomas Goirand wrote: >> On 08/08/2018 01:38 PM, Nikolaus Rath wrote: >>> That doesn't make sense to me. git-dpm maintains (and rebases) Debian >>> patches separately, so upgrading to a new upgrade release can >>> principally not be any harder than with gbp. >> >> It is a nightmare when patches are conflicting. >=20 > Could you give an example where this is handled differently by git-dpm > than by gbp? As I said, the problem is exactly the same. Here's a few cases where it gets nasty. Let's say a patch has been applied upstream. In such case, I just do a few "quilt push" to check, then I see one is already applied (by running "patch --dry-run -P1