On Tue, Jul 15, 2014 at 10:42:15AM +0900, Charles Plessy wrote: > Le Tue, Jul 15, 2014 at 03:26:30AM +0200, Mattia Rizzolo a écrit : > > In fact I'm wondering what is the rationale to stay with the 1.0 format, > > given > > all the benefits of the 3.0 (quilt) format: > > Hi Mattia, > > I am not a big fan of the 3.0 (quilt) format because it imposes a patch > system. > In particular, this format does not make much sense when managing the source > package with Git.
Having followed it up after last year's DebConf, I've been absolutely sold on git-dpm, FWIW; I find it does a great job of making the patch queue pleasant to maintain in a git-native style while providing a nice easy-to-read export to 3.0 (quilt) - that is, you don't actually use quilt manually. At that point 3.0 (quilt) makes a lot of sense to me as an automatable serialisation of upstream + patch queue + packaging with a minimum of package-specific code, and the only way in which it imposes a patch system is that the tools I'm using need to export to it (which is really not that much more than git format-patch with some care about file names, so no big deal, and people can still inspect and modify my source packages without my fancy tools). Getting my head around git-dpm was the tipping point for me to spend some time converting my packages out of bzr or older systems, and now I find myself actively seeking out things I can do with it, which seems to me to be a quite remarkable property in this sort of tool especially given that I started out not being desperately fond of git. And I was going to need some kind of patch queue against upstream in many cases anyway, so it's not as though it adds some new overhead that I wouldn't have had to care about without 3.0 (quilt). A good number of my packages are now just fancy branches of upstream's git repository, which is IMO right and proper. gbp-pq is of course fairly similar. I looked at both although I admit that I only experimented extensively with git-dpm. They both look like they should get the job done, but git-dpm just seemed more featureful and polished to me based on its documentation, and I really like the way it handles the results of rebasing the patch queue. For completeness, the only downsides I've encountered after six months or so of using git-dpm are: * If you have a big patch queue then it can create rather a lot of commits, since changes deep in the queue cause everything after them to be rebased and the tip of the rebased branch merged into master. This is fine in gitk or similar, and it's a clever and useful way to keep track of various versions of a rebasing branch while keeping the end result fast-forwarding, but it can be a little puzzling in things like a gitweb shortlog. * It (perhaps necessarily?) doesn't quite do an exact round-trip of debian/patches/ when you first convert to it, since it exports patches using git format-patch and so changes the format of patch headers a bit. I decided that I didn't find the changes objectionable for my own packages, but it's not entirely obvious how things would work if you were to try to make this scheme work for all 3.0 (quilt) packages in dgit, where you want to make sure to round-trip cleanly. * Not really git-dpm's fault, but the bug fixed in http://www.spinics.net/lists/git/msg234123.html caused some confusion on a couple of occasions when rebasing against new upstream releases. Anyway, worth a look if you haven't already. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140716003504.ga28...@riva.ucam.org
