Raphael Hertzog <hert...@debian.org> writes: > On Wed, 25 Nov 2009, Russ Allbery wrote:
>> I've considered using TopGit to generate a real quilt patch set, but >> it's kind of complicated and I'm not convinced that the work required >> to generate the exported patch tree even with TopGit is really worth >> it. Given that, for packages currently maintained in Git, 3.0 (quilt) >> is extra complexity over 1.0 that doesn't seem to be buying me very >> much. > Why not generate a single patch then instead of a patch set? If that > single patch contains an header explaining why it's not split and where > you can review the changes in a more friendly manner you can have all > the other features of the new format and yet the the situation improve > wrt to knowledge/advertisement of our debian-specific changes. Generating the single patch out of Git is nearly as complex as generating a patch series if dpkg-source doesn't just do it for me (as it does with the 1.0 format). I know 3.0 (quilt) will as well (without any header), but it doesn't really provide any functionality over 1.0 for this use case and adds some extra complexity. However... > I would be ok to add support for this in "3.0 (quilt)": > - add an option "--single-debian-patch" that could be set in > debian/source/options. With this option dpkg-source would update > debian/patches/debian-changes (instead of debian-changes-<ver>) > - support a debian/source/debian-patch-header that would be used > as header of the automatic patch (debian/patches/debian-changes in this > case) > How does that sound? (Thanks to mrvn who suggested me the ideas) ...I think this is a really good idea, particularly since I can understand not wanting, in the very long run, to support multiple patch formats. Seems like a fairly reasonable approach to me. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org