Manoj Srivastava <[EMAIL PROTECTED]> writes: > David Nusinow <[EMAIL PROTECTED]> 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 _______________________________________________ vcs-pkg mailing list firstname.lastname@example.org http://lists.madduck.net/listinfo/vcs-pkg