How to cope with patches sanely

[Florian Weimer]

* Manoj Srivastava:

>         But there is no such linearization, not in the way that quilt et
>  al do it.  The state of such integration is not maintained in the
>  feature branches; it is in the history of the integration branch.  As
>  each feature branch was created or developed, if there were any
>  conflicts, these conflicts were resolved in the integration branch. And
>  the integration branch does not keep track of what changes come from
>  which branch -- that is not its job. And it does not keep the
>  integration patches up to date either -- that again is not its
>  job. Details below.

There are some systems that automatically push changes on a branch to
all branches that branched from it (Clearcase is in that category, IIRC,
and Aegis does something similar).  My experience with Aegis is that
this is usually *not* what you want, and the prevalent DVCS model
uniformly rejects this idea.  However, this would help to get rid of the
integration branch.  Changes to lower branches would bubble up, if
necessary with manual help, and a separate integration branch would not
be necessary.  I'm not sure if this is actually workable (probably not
with the branching model currently in fashion), but it might be.

Anyway, this gets me back to my original question: Is there tools
support for dealing with patch series (quilt or dpatch) which lets me
bubble up patches (including new upstream versions, at least
conceptually) and sink them down the queue?  With three-way merging, so
that it's comparable to typical in-VCS operation?

Has anybody written the converse to git-quiltimport (which should go to
great lengths not to create any gratuitous changes), and a port of that
script to dpatch?