Hi Enrico, Enrico Weigelt: > 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. While I don't agree with your prefered workflow, I think it's a very nice attribute of my proposal, that both workflows could be implemented with it. We could use the same tool and still have different workflows.
Best regards, Thomas Koch, http://www.koch.ro _______________________________________________ vcs-pkg-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
