The problem isn't that developing against a rebasing tree is too difficult, because it's generally not too hard to update things. The problem is that developing against a rebasing tree generates a repository which isn't suitable for inclusion in the rebasing tree. That is, following your instructions would be fine if -next weren't a useful tree to try to get your stuff into, but the resulting repository isn't something that Stephen can pull into -next. I suppose if you're targeting 2.6.n+3 (or later) for inclusion, you could develop against -next, but that's sort of pessimistic. And I think that, if it makes sense to publish your changes at all, it makes sense to have them in a state where they go against vanilla linus. Also note that, if you develop against -next, either it doesn't matter, because you don't have any interactions with other people's changes, or you're going to waste a lot of time when a tree that you interact with gets some conflict and Stephen drops it (requiring you to resolve a slew of conflicts) and then picks it up again the next day (requiring you to resolve the same slew of conflicts the other way, back to essentially the state you had before). And that applies to quilt as well; quilt will happily let the base change under it, but you'll have days when your code won't work without a pile of fixups, and the "bug" it will be due to is that some code that you now require is temporarily and intentionally missing.
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds