patch splitter [Was: Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches]

[Goswin von Brederlow <goswin-v-b@web.de>]

Joachim Breitner <nomeata@debian.org> writes:

> Hi,
>
> Am Sonntag, den 29.05.2011, 11:26 +0200 schrieb Josselin Mouette: 
>> > But it still happens that those patches are generated[1] when the maintainer
>> > did not expect any change at all. That's why we added the option
>> > --abort-on-upstream-changes for maintainers who never wants dpkg-source
>> > to auto-create a patch.
>> > 
>> > I wonder if I should not make this option the default
>> 
>> Yes please.
>
> Iâ??m ok with it, as long as the unexpected changes are put in a patch
> file, either in /tmp or some location cleaned by dpkg-buildpackage, so
> if I want the change I can just move it into debian/patches with an
> appropriate name. 
>
> Basically avoiding yet another call to dpkg-buildpackage
> (--record-changes or something) just to get the patch in place.
>
> I often run dpkg-buildpackage -S just with the intention of recording my
> changes as a patch, as that is more convenient to run "quilt new ...;
> quilt add ..." _before_ doing the changes.
>
> BTW, for all who create patches this way and want to later split the
> patch into two logically independent patches, I am creating an
> interactive patch splitter based on the darcs UI (but only the UI, donâ??t
> worry):
> http://www.joachim-breitner.de/blog/archives/425-ipatch,-the-interactive-patch-editor.html
> (Packaging for Debian is pending, but of course a goal. Until then,
> cabal-install will get it to your computer almost as easy as apt-get
> install.)

Does that include splitting out chunks of the patch and adding them to
already existing patches? Sometimes I get a new patch file and some of
the changes belong to an existing patch. It would be nice if one could
move the relevant chunk directly into the right patch instead of first
splitting and then merging.

MfG
        Goswin