Petr Baudis wrote: > The reason to ponder all this is precisely to _avoid_ rebasing, > which brings many problems - it's PITA to maintain rebasing branches > in a distributed manner, there is no public history record of the > rebases, etc. The alternate solutions try to maintain custom > modifications in a manner that is
What exactly is the problem w/ rebasing ? Once a new upstream is out, somebody simply forks a new branch from the last one, rebases it to the new upstream and publishes it when done. We actually dont rebase _existing_ (already published) branches, but add new ones which just happen to be created via rebase (instead of cherry-picking or appling patchsets manually). > under the presumption that these are desirable properties. With simple > "maintenance-branches" approach, you have to rebase and abandon (i), or > merge repeatedly and give up (ii). No. Each upstream release brings a new distro branch. Trivial. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [email protected] skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- _______________________________________________ vcs-pkg-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
