How to cope with patches sanely

[Ben Finney]

Manoj Srivastava <srivasta at debian.org> writes:

> David Nusinow <dnusinow at speakeasy.net> said:
> 
> > No matter what you want to say about your feature branches, you
> > *must* apply them in a linear fashion to your final source tree
> > that you ship in the package. This is no way around it.
> 
>         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.

Is this (the integration branch and its history of changes) not the
linear sequence of changes that David Nusinow is asking for?

>  And the integration branch does not keep track of what changes come
>  from which branch -- that is not its job.

Doesn't each commit message in the integration branch's history state
what merge you were performing at each revision? You've previously
described your workflow as one where you carefully integrate each
feature branch separately into the integration branch. Do your commit
messages in the integration branch not state what individual feature
branch you're merging in?

It seems to me that the analogue to a linear sequence of patches is
the revision history of your integration branch. Granted, this doesn't
give patches against a pristine upstream except from some initial
state.

-- 
 \     "Some mornings, it's just not worth chewing through the leather |
  `\                                          straps."  -- Emo Philips |
_o__)                                                                  |
Ben Finney