Re: using git-dpm or plain git-buildpackage in PAPT and DPMT (was: PAPT Git)
On 08/10/2016 09:21 AM, Sandro Tosi wrote:
> On Tue, Aug 9, 2016 at 11:50 PM, W. Martin Borgert <debacle@debian.org> wrote:
>> On 2016-08-09 23:28, Daniel Stender wrote:
>>> On this occasion ... let it be me to start the discussion: let's get into Git
>>> also for Python Apps soon.
>>
>> A common VCS for both DPMT and PAPT would be nice, indeed.
>
> should we try and use plain git-buildpackage instead of git-dpm?
Piotr avoided the discussion during Debconf 16. IMO for good, as it
would have probably taken a full session.
I wrote a draft about my thought about it. Let me past it here.
The biggest defect of git-dpm, to me, is that it is often very painful
to merge a new upstream release in the packaging branch. Instead of
accepting the merge, and resolving conflicts later on, git-dpm goes into
the rebase conflict mode of Git, and it's often not obvious what to do
there. Messing-up everything, and restart from scratch (and then iterate
until done properly) isn't uncommon. Sometimes, all of this time is
spent just for a patch that needs to be removed removed.
With git-dpm, many operations aren't obvious, and it seems there's not
even an answer for stuff like this:
https://bugs.debian.org/810580
https://bugs.debian.org/801667
https://bugs.debian.org/801666
which stayed opened with no reply for months.
Sometimes, things are just very annoying:
https://bugs.debian.org/763569
https://bugs.debian.org/813302
https://bugs.debian.org/768382
https://bugs.debian.org/801649
It is also annoying that git-dpm doesn't produce a clean git history. It
ends up this way:
commit 241398abe0c476f39f0b4d62fb5227e4d0a52778
Merge: c72e5ea 880b748
Author: Thomas Goirand <zigo@debian.org>
Date: Tue Aug 2 08:40:37 2016 +0000
merge patched into master
commit 880b74889bbba237fe1bb17d992e1cbbb462be6b
Author: Thomas Goirand <zigo@debian.org>
Date: Tue Aug 2 08:39:49 2016 +0000
django-1.10-fix_runtests_lack_of_TEMPLATES
when really, this should be a single commit, not a merge operation. This
also doesn't include the debian/changelog comments, which also should be
in the same commit.
Even more: the generated patch headers aren't compliant with the format
1.0 as defined in the DEP. Meaning that we have to rewrite them. But
worse: git-dpm rewrites the headers loosing precious information like
the Origin field or bug numbers.
git-dpm also fails to tag upstream/foo automatically when importing a
new version. I've been told to use "git-dpm tag", but that's not
obvious. My own experience managing debian/patches quilt patches
manually or through gbp pq is actually much much nicer.
Plus it appears git-dpm is unmaintained and even sometimes buggy
(according to what I heard from others in Debconf: I didn't experienced
crashes myself). The non-mandatory use of "gbp pq" is nicer approach:
those who prefer manual quilt handling can do it.
As I only heard complains about git-dpm, maybe someone would like to
express his joy using it, and explain why they think it's a nice tool.
But is there such person? It seems git-dpm only brings frustration.
Cheers,
Thomas Goirand (zigo)
Reply to: