On 08/10/2016 09:21 AM, Sandro Tosi wrote: > On Tue, Aug 9, 2016 at 11:50 PM, W. Martin Borgert <deba...@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 <z...@debian.org> Date: Tue Aug 2 08:40:37 2016 +0000 merge patched into master commit 880b74889bbba237fe1bb17d992e1cbbb462be6b Author: Thomas Goirand <z...@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)
