- To: email@example.com
- Subject: unsubscibe
- From: JT <firstname.lastname@example.org>
- Date: Tue, 05 Jun 2012 19:05:10 +0200
- Message-id: <4FCE3C46.email@example.com>
- In-reply-to: <firstname.lastname@example.org>
- References: <20120515091028.GB24635@debian> <20120516103849.GA32036@angband.pl> <201205171041.42381.Chris.Knadle@coredump.us> <email@example.com> <4FB5F914.firstname.lastname@example.org> <20120518093708.GA4882@angband.pl> <20120518121640.526aac60@ileemo> <20120518114158.GC4882@angband.pl> <20120518140907.GE425@khazad-dum.debian.net> <email@example.com> <20120521005524.GA24092@bongo.bofh.it> <firstname.lastname@example.org>
Am 01.06.2012 12:17, schrieb Goswin von Brederlow:
md@Linux.IT (Marco d'Itri) writes:
On May 18, Russ Allbery<email@example.com> wrote:
I do this work in cases where keeping the patches separate is useful for
some reason, but mostly it's not.
Some of my packages have 30-60 patches ("mature" software...), and
merging them would make them impossibile to understand.
Is there a VCS workflow which would make such packages easier to manage
than with quilt? (I like quilt, BTW.)
Check out gitpkg. It has hooks to create the quilt patches from a set of
feature branches in some form.
Also note that in this scheme where you produce a single debian patch
you would not be working on the single debian patch. You would still
work on your 30-60 feature branches (or whatever else you use instead of
a patch queue). The single debian patch would just be the fallback for
people that can't access your VCS.
The single patch would be hard to understand but it would be unfair to
compare it to 30-60 patches in a patch queue. What you have to compare
the single patch with is a single debian diff.gz. Obviously if you can
make a meaningfull patch queue with seperate patches that is
preferable. The single patch method is for situations where you can't.