On Sun, Feb 24, 2008 at 05:10:16PM -0800, Russ Allbery wrote: > Ben Finney <[EMAIL PROTECTED]> writes: > > Manoj Srivastava <[EMAIL PROTECTED]> writes: > > >> 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? > > Yes, but you don't, in the general case, completely develop some feature > on a branch and then merge it only once. You do some work on one branch, > merge it, do some work on another branch, merge it, do more work on the > first branch and merge it again, import a new upstream and merge it into > all of your branches, do some more work on the feature and merge it > again.... > > I can see Manoj's point. It's not at all clear to me that there's a > useful linearization of the feature branches after that sort of workflow > has continued for a while. > > (I'm now maintaining two of my packages using only Git and feature > branches without any patch system so that I can get some practical > experience with this and understand the workflow better.)
The problem is that you and Manoj assume that this is the only way to do things. I don't believe this. Pierre Habouzit has been experimenting with an alternative method of feature branches that exports to a linear stack of diffs just fine. Just because Manoj is doing something one way right now doesn't mean it's the only or even the correct way to do it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
